Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #81956

RE: ORM opinion

From "Joseph L. Casale" <jcasale@activenetwerx.com>
Subject RE: ORM opinion
Date 2014-12-04 23:20 +0000
References <CAPTjJmrix4KtLwf4S6kDHYsNLGT5KdYxhrju-0rS8GOyJGa9CQ@mail.gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.16593.1417735282.18130.python-list@python.org> (permalink)

Show all headers | View raw


> First recommendation: Less layers. Instead of SQLAlchemy, just import
> sqlite3 and use it directly. You should be able to switch out "import
> sqlite as db" for "import psycopg2 as db" or any other Python DB API
> module, and still have most/all of the benefit of the extra layer,
> without any extra imports.

Yeah, I am a fan of apsw but this is what I have now done. While I am
fine with writing my own abstractions, its certainly less overhead using
an orm.

> Secondly, see if you can keep the Python process running, instead of
> separately invoking it for every operation. This will mean some
> structural changes, but if you're specifying Python as the plugin
> interpreter (as opposed to, say, "execute this program with these
> args", which is far more general), you can probably set up a wrapper
> script that calls on the user code repeatedly. Perhaps you could have
> a multiprocessing.Queue feeding tasks to the subprocess, via a little
> parent Python process. If you can't make those kinds of changes to the
> application, the next best would be a stubby driver process that feeds
> jobs to your real subprocess; the real work might be done by a
> Unix/TCP socket server, and the stub connects, feeds it some
> information, gets back a result, and disconnects. The stub will have
> an extremely minimal set of imports (the bear necessities of life, if
> you like), and the real process can import as much as it likes,
> because it won't be doing it for every operation.

I am stuck with the current architecture, but the idea you propose has
been thrown around, truth is I am not certain if we are enduring the
effort of such a large rewrite that Python is the tool to use (this is a
Windows application) but regardless your idea is one that is proposed.

Thanks,
jlc

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

RE: ORM opinion "Joseph L. Casale" <jcasale@activenetwerx.com> - 2014-12-04 23:20 +0000

csiph-web