Huy wrote:
IMO Python does not have a powerful enough ORM. Although most of these solutons provide the simple selects, updates, inserts and joins none of them provide good handling of legacy databases or flexibility of using the sql of your choosing (which I think is crucial, there is no point doing certain things one way and other things another way).
I think in all of them you can use your own SQL, to a degree. In SQLObject the limit is usually in *what* you select, not *how* you select it, so everything after WHERE is up for grabs.
I don't know why most ORM try and hide the "select * from table" and leave the where configurable. It's then worst if they then use a special syntax to emulate SQL for the where expressions rather then just plain SQL, especially when the special syntax doesn't even deal with anything remotely complex i.e just simple "and", "or" type things.
I don't know about others, but I find myself needing the full power of SQL; functions, grouping, ordering, subselects etc. and I want my ORM solution to provide a simple, consistent and explicit interface between my database data/interaction and my application domain objects. I really don't like doing certain things one way and other things another way. Isn't this the python way ?
The only ORM tool I know of which provides a good solution to ORM is a java product called ibatis sqlmaps. Any python ORM would do well to have a similar design.
In fact I rolled my own ORM for a client which provides pretty much the same as the ORMs above (although I think it's nicer because it has a beautiful metadata model which can be accessed for generating guis, code etc. and has not restriction of database schema, can handle multi key joins) and after using it for a while I still prefer ibatis for more complex applications.
I think any ORM which enforces a database design (eg. key has to be integer id etc.) is of no use except for the simplest applications.
Well, to the degree that ORMs imply certain conventions, they are usually good conventions, and if you are starting from scratch or have the ability to refactor your database then those conventions aren't that burdensome.
Thats a great many "ifs" there. It's true that I would love to redesign many of the databases I get to work with but almost 90% of the time it is impossible due to the massive amount of legacy applications still relying on it. True for start from scratch applications (which usually start off very simple) ORMs like sqlobject can help you get up and running quickly but I'm not so sure what they can do for you once you get into harder stuff which are straight CRUD operations.
On the other hand, I would hate for any ORM to dictate the way I design my databases. The principle of the thing just doesn't make sense. I use an ORM to help me map my database to my domain objects, not to help me design my database so that I can map them to my domain objects.
And in most cases (at least for SQLObject) there are ways to deal with legacy databases, or ways to create a heterogeneous system where you use an ORM for some tables, and custom SQL for other situations.
SQLObject is pretty good for CRUD applications. But I can imagine that if it evolves into providing more features for advanced usage (in terms of database interaction) you may start seeing things get more and more complex with its current design.
If you are thinking in terms of heavily relational queries -- lots of joins, subselects, aggregating, etc -- an ORM generally will feel clunky. Many relational concepts don't map well to Python ORMs. Some of those concepts could be represented in an ORM (but just aren't currently), and some are very difficult to represent.
Which is why sqlmaps is so good. It does not feel clunky and I can do anything sql allows me to do and map it any which way i choose to do so. The true power of sqlmaps comes into play when you use it with a framework like the spring framework which provides declarative transactions for your DAOs. Although I dislike Java and love Python, I have to admit that python is very far behind when dealing with databases and transactions. It's definitely possible in python but it's so much more clean in Java (using spring).
Looking just briefly at sqlmaps, it looks like a thin object interface on top of custom SQL queries.You're pretty much correct there. It's a very thin interface but the beauty of it is it's mapping features both for database queries (where statements) and database results (mapping resultsets to domain objects).
I'd find that tedious, but if you are going to write custom SQL then I'm sure that's a helpful way to organize the SQL.
It's not much more tedious then SQLObject but it is far more powerful when it comes to mapping then SQLObject. Most of the mapping is only done once and can be considered equivalent to declaring SQLObject classes. You don't even need to do any mapping if you don't want to. You can treat the sql statements (select, insert, delete, update) like method/functions which take named paramters via a dictionary or straight parameters for simple usages.
Some of my applications are used by multiple clients with very different database schemas (although most of the information is the same, the structure is very different (including different column names)). SQLMAP allows me to keep my application code the same no matter which database schema I am using. I just need to of course provide the two different mappings (to the same sets of domain objects) and configure the one to use depending on the client.
It's a lot different from Python ORMs, and I think I'd find it a bit clunky.
In a way it almost reminds me of Zope's Z SQL Methods, which I hate.
I don't think it's clunky but to each his own opinion. I haven't looked at Zopes Z SQL but I've never liked Zope, mainly because of that ZODB that they are always marketing.
*** WARNING OT RANTING, SKIP IF NOT INTERESTED ****
What the heck is so special about ZODB or any object oriented database. They are all just glorified session stores just like the one in Webware :-) except webware doesn't pretend it's some u beaut state of the art thingy.
*** END RANTING ****
Cheers,
huy
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Webware-discuss mailing list Webware-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
