On 10/26/05, Todd Greenwood <[EMAIL PROTECTED]> wrote: > > I don't mean to be fresh, but why use an ORM at all? I'm finding that > the learning curve for SQLObject is a bit steep. And then, when I > really need to do something, which will nearly always involve joining > multiple tables, I have to write a bunch of gibberish that really looks > alot like SQL joins.
One thing I failed to mention in the other thread is that you need not use SQL-ish joins for the kinds of things you were doing. Why not use straight Python? For example, p = Page.get(1) entries = p.entries entries.sort(key=lambda e: e.sortkey) (written in mail, so usual caveats apply, and I don't remember what you were sorting on..) As much as is humanly possible, I do things the Python way and let SQLObject sort out the database stuff. This keeps my code clean and easy to work with. Doing things that way, I seldom use joins. More often than not, I'll do a select against one table (which is pretty straightforward, I think) and then use the object traversal features to get to what I want. When performance improvemenst are required, that's when I start to look at other kinds of selects and the possibility of doing straight DBAPI. > Sure, if I was in javaland, then I would be using hibernate and HQL to > abstract away the db layer so that I could swap db implementations with > just a config file change. But I'm not at all sure that you get that > with SQLObject. Sure you do. You do have to live within the constraints of the database, though. For example, the first version of the 20 Minute Wiki tutorial didn't have the "length" parameter on the pagename column. sqlite is fine with that. MySQL is not. Otherwise, people have run that code on sqlite, MySQL and PostgreSQL. > As a related issue, any project of any size is going to want to > abstract the database away and present a facade that will in turn talk > to the db. The facade (or db wrapper, whatever) could use an ORM, or be > jython talking to java + hibernate/jdbc, or use DB-API...etc. DBAPI is pretty low-level. It's equivalent to doing JDBC... it gets you a common interface to databases, but the language used by the database is not abstracted out at all. There are other packages available for Python that solve the problem in a variety of ways. SQLObject is a good solution for a great number of apps, in my opinion. It's also not that hard to hack on and has a fairly extensive test suite, so people shouldn't be afraid of extending it if they have something specific in mind. It is worth discussing ideas for API changes on the sqlobject list, because Ian and Oleg have both thought about the issues are fair bit. Kevin
