hi David - I know that Jonathan continues to have strong opinions on this matter. Personally, I think SQLObject is a perfectly good ORM that should remain in wide use. There is one very major issue with it, which is that AFAIK it doesnt use bind parameters which leaves it open to SQL injection attacks. It seems Ian seeks to fix that in SQLObject2. But otherwise, it fits the bill for people just getting into database/domain object development; everyone starts with active record, I certainly used to write all kinds of active record libraries. its the most intuitive thing to do.
In some ways, SQLObject's notions of "your object IS a row, your object's attributes ARE columns" are so simplistic that its almost like you *should* work with it first, and only until you realize that hey, my object is *not* a row! my attribute is *not* a column ! is it time to move on. the point of SQLAlchemy is for when you have been around the block with active record and your SQL skills far exceed what you can get done with active record, when you realize that your domain objects are starting to become independent of the way they are stored and dont want to just map to a table, when you are architecting systems which can take advantage of a standardized workflow and benefit from the performance and stability benefits unit of work can give you, and when you are working in an environment where theres a lot of real-world constraints, standards, practices such as bind parameters, pre-existing schemas, the need for hand-optimized queries, etc. that require a tool flexible enough to handle all of it, but is still taking advantage of the Python language...its the SQL/ORM tool I wanted for myself. It seems that there is also a contingent of SA users who seem like they would much prefer a fully working SQLObject, i.e. they totally like SQLObject's philosophy and design but they just came up against a wall with certain bugs or maybe its lack of join support, oracle support, whatever, so they come to SA which takes a more enterprisey tack on some of those issues. For those folks, they are welcome in the SA community, and the ActiveMapper stuff represents an effort for those folks to create the active record ORM that they want, using SA as a base. If ActiveMapper gets some more air under its wings, then that would be a more reasonable "direct" alternative to SQLObject. - m David Geller wrote: > I realize that SQLAlchemy is far more flexible and extensible than > SQLObject. But for simpler things, what exactly are the differences > between them? > > For a newbie starting out, what would you say are the > advantages/disadvantages to each? > > And if what you are doing is fairly "simple", is it worth using SA, even > if it is more "work" to get things done? > > Thanks. > > > -David Geller > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Sqlalchemy-users mailing list > Sqlalchemy-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
