Jonathan LaCour wrote: > > I find it to excel at the complex, and falter at the simple. I am > extremely excited to hear that you are working on a more declarative > SQLObject-like layer to SQLAlchemy, as it would address my *one* big > gripe with it: its just too complex for the simple stuff. >
Hi Jonathan - Can you give me an example of a simple task it falters with ? So far, youve made other comments to this effect, but you havent mentioned what exactly is so complicated. For my part, I cant imagine how much simpler it can be. A few people were helpful enough to make suggestions on the mailing list, such as a "select_by" and a "get_by" method, and easier ways to attach these methods to a class; theyve been added (as will any other reasonable suggestion). The "select_by"/"get_by" methods are even more powerful than typical active record "find_by" methods, while adding zero complexity on the calling side, in that they will even pull in a related join if you search by a key that is not on the main class but on one of its relations. Similarly, it seems that people are accustomed to saying "foo=ForeignKey(), bar=MultipleJoin()", and are thrown off by how these keywords are not present in SQLAlchemy. This is an example of a simpler approach being mistaken for a more complicated one, just because it is unfamiliar. With SQLAlchemy, all you say is, "foo=relation(), bar=relation()". It *figures out* the relationship for you based on what it naturally is based on foreign keys. If you have auto-loaded your tables from the database which has proper foreign key constraints, SQLAlchemy will literally automatically configure object relations based on the database schema, with no explicit code in the application. Simpler ! More automatic ! Only one function to learn instead of four or five ! Combine features like this with all the extras, like eager loading, deferred column loading, automatic support for self-referential tables, and the fact that O/R complexity will increase with a relatively smooth correlation to the complexity of the application and database itself, rather than making a sudden jump beyond simple cases, and SQLAlchemy becomes even easier to live with....all for just the simple price of looking outside the way youve been doing something all these years. I know that people are comfortable with SQLObject, and may prefer its style. However, what I am trying to do with SQLAlchemy is make life easier for those who understand how databases and relational structures work; for those people, a tool like SQLAlchemy makes simple tasks *simpler*. And the more it allows those not accustomed to relational structures to learn to see their database as the powerful relational tool it is rather than a substandard object repository, the more they will see SQLAlchemy's relational concepts making their jobs easier than with the object/table mappers they are used to.
