python ORM
flyingfrog
do what i want with it... Before that i used java Hibernate, think you
should know about.
I've tried both SQLObject and SQLAlchemy but both have been a delusion
:(, i'd like to share with you my considerations, hoping in some
suggestions!
SQLObject forces you to embed "database code" into your model classes,
and i don't really want that. And it's really buggy! Too much for
production usage.
SQLAlchemy lets you define separately DB code and python classes, but
then you hve a real duplication. And to use database functionalities
you always need to access session objects or connections, making
sql-like queries. And i don't want that.
Thy're both good projects but none of them has catched the real
objective: no more sql within the application logic. Hibernate does it,
take a look!
Anyway, maybe i didn't look so much into python world and there could
be other tools, or other ways of using these tools for doing what i
want to, please let me know if you know of any!!
Bye
Sanjay
> SQLAlchemy lets you define separately DB code and python classes, but
> then you hve a real duplication. And to use database functionalities
> you always need to access session objects or connections, making
> sql-like queries. And i don't want that.
Using "assign_mapper" rather than "mapper" is the solution to this?
sanjay
kap...@gmail.com
over many years. if you want to help make sqlalchemy better for yours
and other usage. its much better to give concrete examples, that can be
used to improve it, then making grandiose negative statements. the idea
behind sa's orm is indeed to obviate the need for most common
application sql, if it fails for some reason on a given example, it
would be helpful to actually here what the usage scenario/example is,
perhaps you can post a comparison of a simple model between hibernate
and sa.
for example.. usage complaints as relates to session, are typically
things that can be handled by app server, via app agnostic appserver
integration. sa exposes various session/txn layers for application
flexibility and for easier integration into frameworks or different
programming styles, in much the same way that hibernate does, and
arguably sa is more flexible here for different usage modes (although
hibernate's scaling/deployment options, ie. caches are much nicer).
cheers,
kapil
Kevin Dangoor
> SQLAlchemy lets you define separately DB code and python classes, but
> then you hve a real duplication. And to use database functionalities
> you always need to access session objects or connections, making
> sql-like queries. And i don't want that.
Unless Hibernate has changed almost entirely in the past two years
(when I was last using it), you used session objects to control which
of your objects were currently being managed by the ORM and you used
OQL to query the database. I'd certainly be interested to see some
examples of how it works now to see how it has changed...
Michael Bayer
upon its own SQL-like language HQL, has a way more verbose config than
SA, and yes is totally designed around a session just like SA), and
also misses the point of SA which is that SQL *is* the best way to
query your database, if you can just iron out the usual issues with
database quirks and object-relational mismatch. disproving the myth
of "the best database layer is the one that makes the database
invisible" is a primary philosophy of SA. if you dont want to deal
with SQL, then theres little point to using a database in the first
place.
Hibernate is pretty SQL oriented as well, and as I use it every day for
my job I can say it has little to nothing over SA...harder to
configure, more complex and less consistent behavior with regards to
relationships, poorer database support (like forget about quoting and
stuff), its "create schema" support sucks, no reflection, only one
"eager loading" relation at a time, no union-based polymorphic loading,
self-referential relationships are barely supported, and of course its
very hard to integrate plain SQL/result set logic with it since its
only an ORM. the only compelling features it has over SA are "extra
lazy loading" and a second-level cache, which while ive used neither,
could be implemented for SA someday.
Kevin Dangoor
> Hibernate is pretty SQL oriented as well, and as I use it every day for
> my job I can say it has little to nothing over SA...harder to
> configure, more complex and less consistent behavior with regards to
> relationships, poorer database support (like forget about quoting and
> stuff), its "create schema" support sucks, no reflection, only one
> "eager loading" relation at a time, no union-based polymorphic loading,
> self-referential relationships are barely supported, and of course its
> very hard to integrate plain SQL/result set logic with it since its
> only an ORM. the only compelling features it has over SA are "extra
> lazy loading" and a second-level cache, which while ive used neither,
> could be implemented for SA someday.
Sounds like you should port SA to Java so you can use it in your day job :)
Kevin
David Shoemaker
-shoe
--- I'd give my right arm to be ambidextrous. ---
metaperl
product is on its way though.
Ilias Lazaridis
Ο/Η flyingfrog έγραψε:
> Ok, this is my first approach with python + ORM, and i must say i can't
> do what i want with it... Before that i used java Hibernate, think you
> should know about.
Python fails in this discipline mainly due to:
* the lack of collaboration between projects (mainly
'single-developer' centric)
* user feed back is not tacke nin account as it should
http://case.lazaridis.com/wiki/Persist#Requirements
Ilias Lazaridis
Ο/Η metaperl έγραψε:
> TurboEntity was quite sweet. Supposedly a complete rewrite as a new
> product is on its way though.
the first major problem of this rewrite:
it happens 'silently' (non-public)
.
Michael Bayer
(youd go to the site and just get a "coming soon"-style splash
page)..and even then it was already in production use in earlier forms.
they knew that if you release something that wasnt polished and would
lead to user frustration, people would get disinterested and leave.
the strategy seems to have worked for them.
its not your grandfather's open source community !
Alan Franzoni
SQLAlchemy lets you define separately DB code and python classes, but
then you hve a real duplication.
Duplication is bad, but you're never forced to duplicate anything.Python offers all the tools you need to prevent duplication, and SA offers whatever you need to 'extract' metadata from tables in order to employ it. Take a look at what ActiveMapper does.
I'll give you the example implementation of my system: I have defined my own database through sqlalchemy.
Then I write the 'base' DB class for my system (which may vary depending on the software I'm working on) and I use a custom metaclass I've created to sort out all the object-related issues.
In the end, I get a full-working set of mapped classes without ever duplicating a single line of code, unless I want to override a default behaviour.
Of course, since SQLAlchemy can't know what are you doing if you use 'strange' naming (well, I guess this could be sorted out anyway by harvesting globals(), but it's a slow approach), you'll have to trade naming convention for 'singleness' - e.g., if have a table called 'place', its corresponding object will be named 'Place'. And if, in another class, I have a FK column called 'place_id' it will point (for sure!) at the place.id column, and that class will have a 'place' property.
Try it out, you'll find amazing how easy it's to write such code.
--
Alan Franzoni <alan.fra...@gmail.com>
-
Togli .xyz dalla mia email per contattarmi.
Remove .xyz from my address in order to contact me.
-
GPG Key Fingerprint (Key ID = FE068F3E):
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E
Robin Munn
If you're responding to Ilias Lazaridis's comment, you should be aware
that he appears to be a troll. His post set off all my "trolling post,
ignore" sensors, plus I've seen him before. (Here, several months ago,
if I recall correctly). Incidentally, there used to be a Wikipedia
article on him, which was recently deleted. But you can still see it
via Google's cache, at:
I wasn't going to say anything unless someone responded to him, but in
the interests of pro-actively heading off a possible flamewar:
Please Don't Feed The Trolls. :-)
--
Robin Munn
Robin...@gmail.com
GPG key 0x4543D577
Michael Bayer
thread was more or less a troll as well IMHO but everyone seems to be
responding to it anyway. but django's initial release strategy is on
my mind regardless...i have something else im hopefully releasing soon
but im purposely keeping it under wraps until its as done as I can get
it.
Alan Franzoni
Michael Bayer
come onto a board and say, "project X sucks. project Y is so much
better, you should rewrite project X to be just like it, because
project Y doesnt have issues A, B and C like project X does, plus it
does D, E and F" where anyone thats ever used Y for five minutes knows
that A, B, and C are completely key issues with it that are greatly
improved in X, plus its very obvious that X already has D, E, F and
even G, that seems like you are putting out easy bait for people to
chomp on. to me thats a troll.