Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #81957
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Subject | Re: ORM opinion |
| Date | 2014-12-04 23:32 +0000 |
| References | <CAPTjJmrix4KtLwf4S6kDHYsNLGT5KdYxhrju-0rS8GOyJGa9CQ@mail.gmail.com> <1417735208769.37132@activenetwerx.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.16594.1417735967.18130.python-list@python.org> (permalink) |
On 04/12/2014 23:20, Joseph L. Casale wrote: >> 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 > Anything listed here http://www.pythoncentral.io/sqlalchemy-vs-orms/ you've not heard about? I found peewee easy to use although I've clearly no idea if it suits your needs. There's only one way to find out :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: ORM opinion Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-12-04 23:32 +0000
csiph-web