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


Groups > comp.lang.python > #81957

Re: ORM opinion

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)

Show all headers | View raw


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


Thread

Re: ORM opinion Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-12-04 23:32 +0000

csiph-web