was about RDBMS integration in Python (hint: SQLObject and
SQLAlchemy both start with 'SQL').
...
Of course it's relevant.
Of course not.
I'm just wondering what everyone's preference is, and why, and if
there are even more choices for ORM.
You may not know it but the R in ORM stands
alex23 wrote:
lazaridis_com wrote:
The persist case evaluates python persistency systems (or
mechanisms), and will show my personal preference:
Do you feel that evaluating-for-evaluation's-sake produces a more
measured understanding of the value of a product than that taken from
its use
since there's a clear indication that the
OP question was about RDBMS integration in Python (hint: SQLObject and
SQLAlchemy both start with 'SQL').
...
Of course it's relevant.
Of course not.
You are right.
It's not relevant for _you_.
I'm just wondering what everyone's preference
was about RDBMS integration in Python (hint: SQLObject and
SQLAlchemy both start with 'SQL').
...
Of course it's relevant.
I'm just wondering what everyone's preference is, and why, and if
there are even more choices for ORM.
The persist case evaluates python persistency systems (or
mechanisms
lazaridis_com wrote:
The persist case evaluates python persistency systems (or
mechanisms), and will show my personal preference:
Do you feel that evaluating-for-evaluation's-sake produces a more
measured understanding of the value of a product than that taken from
its use in, say, actual
: SQLObject and
SQLAlchemy both start with 'SQL').
good night.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Jorge Vargas wrote:
On 8/31/06, John Salerno [EMAIL PROTECTED] wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices
John Salerno wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.
Thanks.
You can review the Persit Case,
lazaridis_com wrote:
John Salerno wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.
Thanks.
You can
Ο/Η Bruno Desthuilliers έγραψε:
lazaridis_com wrote:
John Salerno wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.
Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
John Salerno wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.
Thanks.
Currently most of my work is
Adam Jones wrote:
I think SA's extra flexability
is worth the effort.
Thanks for the reply. Do you mean in the above quote that SA is a little
more complicated than SO?
--
http://mail.python.org/mailman/listinfo/python-list
John Salerno wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.
I just finished surfing both websites last
John Salerno wrote:
Thanks for the reply. Do you mean in the above quote that SA is a little
more complicated than SO?
Don't be afraid to download them and try their respective tutorials.
Each one would take about an hour and then you'd have a feel for
yourself. I agree with adam that
John Salerno a écrit :
Are there any major differences between these two?
Yes. SQLAlchemy is, mainly, a very higher-level DB-API that makes
working with a RDBMS almost transparent (no embedded SQL unless you
really wants to) without trying to pretend there's no RDBMS nor forcing
you into ORM
John Salerno wrote:
Adam Jones wrote:
I think SA's extra flexability
is worth the effort.
Thanks for the reply. Do you mean in the above quote that SA is a little
more complicated than SO?
Yes, it is. To avoid the technical issues involved the complication can
be summarized as:
I think this post by the author of SQLAlchemy perfectly summarizes the
differences between the two ORMs:
http://article.gmane.org/gmane.comp.python.sqlalchemy.user/1072/
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
BJörn Lindqvist [EMAIL PROTECTED] writes:
I think this post by the author of SQLAlchemy perfectly summarizes the
differences between the two ORMs:
http://article.gmane.org/gmane.comp.python.sqlalchemy.user/1072/
And ActiveMapper is working to some extent better than it was by the time of
the
On 8/31/06, John Salerno [EMAIL PROTECTED] wrote:
Are there any major differences between these two? It seems they can
both be used with TurboGears, and SQLAlchemy with Django. I'm just
wondering what everyone's preference is, and why, and if there are even
more choices for ORM.
they use two
Jorge Vargas [EMAIL PROTECTED] writes:
for example SA wins at using an existing db
but SO wins at not worring about the db structure
That's not entirely true. Some things are impossible with SQL Object alone.
You have to, at least, make use of sqlbuilder. And these aren't hard things,
mind
21 matches
Mail list logo
