Jonathan Ellis wrote:
On 3/18/06, *Alan Franzoni* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Now, my 2c: do we really need *two* ORMs in the Python community?
I agree that we do not.
But really this sentiment should be directed towards Ian Bicking; he's
finally (implicitly) admitted that SqlObject is a dead end, but instead
of throwing his weight behind a better ORM, he insists on fragmenting
things again. Oh, well.
I haven't said SQLObject is a dead end. I think the codebase needs
rethinking, as well as thinking about what its scope should really be.
For people who are not fiddling around with SQLObject's internals
SQLObject 2 will provide the same API and a comfortable upgrade. And of
course SQLObject will never meet everyone's needs; I'd like it to be
easier to use in a heterogeneous environment.
And "fragmenting things again"? I don't know what you are talking about
there. Continuing the SQLObject line is not fragmenting things at all.
SQLObject is, after all, the older project.
Haven't you (Ian and Micheal) ever
considered a merge?
Perhaps if more people urged Ian to consider this, he would. I know I
have, to no effect. He doesn't even want to re-use the lower-level
(sql) layer of SA. Maybe his vision of how ORM should work is really so
different that the world does need an SqlObject2. But I doubt it.
I'm not really comfortable making SQLObject a subset of SQLAlchemy.
There is, for instance, what I think could be considered a data mapper
inside SQLObject2 -- kind of an accidental implementation detail. It's
maybe 20 lines of code. It's not exactly the kind of thing that makes
me desperate to look for opportunities for code reuse.
There is, however, significant opportunity for code reuse between the
two projects. And these aren't the only two projects out there either
-- there's other ORMs, and people who aren't comfortable using any ORM.
I've been trying to keep these things extracted from SQLObject2 in the
form of SQL-API (http://svn.sqlobject.org/sqlapi/trunk). I would
certainly be interested in reuse on that level, and I'm very open to
suggestions and changes, or whatever. It's intended to be a more useful
layer on top of the DB-API.
I did look at SQLAlchemy before writing sqlapi.sql (which is like
sqlobject.sqlbuilder or sqlalchemy.sql). There were some small details
which bothered me in SQLAlchemy, particularly the binding from SQL to a
specific database engine. sqlapi.sql follows sqlbuilder in this
respect, where an expression is abstract from any backend until it is
actually executed. To me SQL expressions seem intrinsically like value
objects, and binding them to a specific connection I think breaks that
basic principle. There was some other things in SQLAlchemy that I
didn't understand, they might be fine. I'm not committed to any
internal representation there, or even the implementation currently
provided, only some basic principles. Potentially the collaboration
could simply be in terms of some magic methods.
Some other parts of SQL-API are I think thoroughly outside of the core
scope of both SQLObject and SQLAlchemy; things like creating, pooling,
and potentially configuring connections. These things in SQL-API can be
used in part or in whole. Also, there is a public interface for
database portability, both for providers and consumers. It's probably
more explicit than it should be in some places, and it certainly isn't
transparent (I don't think it can be transparent). But it would be nice
to share that experience. Though it's a messy enough problem that it
occurs to me maybe it shouldn't be part of the SQL-API interfaces directly.
Lastly, it would be great if there could be some collaboration on a
combined administration/migration tool, similar in scope to
sqlobject-admin. ORM-specific administration isn't really very useful
-- especially when you can't be sure the ORM describes anything similar
to what some legacy database looks like (before the upgrade). And the
kinds of functions you want to upgrade a database (ALTERs and table
introspection, etc) are relatively uncommon in everyday database use, so
including them in an ORM is unnecessary scope creep. I think a
cross-ORM tool (and just as applicable to no ORM) would be an easy place
for collaboration.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
-------------------------------------------------------
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
