well there are already two projects in this vein:
http://cleverdevil.org/computing/35/declarative-mapping-with-sqlalchemy
http://trac.pocoo.org/wiki/DatabaseApi
On Mar 26, 2006, at 2:57 PM, David Geller wrote:
I realize that this is up to Ian, and I know he has some problems
with certain aspects of SA architecture, but doesn't it make sense
for there to be a "SO compatibility layer" to SA, rather then
continuing a completely separate SO? This, since it seems SO
performs a subset of what SA is capable of.
Others have said this already. Just my 1/2 cent.
David
Michael Bayer wrote:
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
-------------------------------------------------------
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
