> 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.
I was hoping to get around to implementing a migration system similar to
RoR's migration system. It's being used to good effect in production
environments.
It's not perfect but it's at least an attempt to provide a managable
framework for upgrades (and downgrading if necessary). It essentially
works by having up() and down() methods in a Migrator class which
contain functionality to upgrade/downgrade respectively. It's not
automated - the methods contain the necessary calls to create/remove
fields and populate data etc if they need to.
But, unless I'm mistaken, currently SQLObject doesn't abstract dropping
of indices and a few other necessary methods supporting full table alter
abilities.
Will at least enough functionality to add/remove columns and indexes be
present in the sqlapi layer? I'd suggest that it's needed so that we
can write tools that sit on top of SQLObject without having to write an
independant database abstraction library (repeating a lot of code no doubt).
Justin
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.
-------------------------------------------------------
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
