well it seems like the approach youve taken with your application
is having somewhat of a clash with the application approach
fostered by SQLAlchemy's ORM. The general idea with the SA ORM is
that you worry about your objects and associating them together,
but you typically never need to deal with the primary keys
explicitly, those are handled for you.
However, if you do need the IDs explicitly, just create them
yourself, using a sequence, stored procedure, or whatever, and
assign that to the appropriate ID attribute on your object. When
it gets INSERT'ed by the ORM, thats the ID that will be used. the
defaults you create on Columns can be executed manually , i.e.
id = mytable.c.mycolumn.default.execute()
(more for the docs....)
I think that you are going to find more and more people who want to
do things differently than this, and I think it would be a valuable
option for SQLAlchemy to support a lighter, more database-y ORM
methodology in addition to the way it behaves now. This is what
Aaron Bickell (one of my coworkers) ran into when trying to replace
our home-grown database layer with SQLAlchemy, and what inspired him
to write his simple object layer.
In the application Aaron was working with, we rely entirely on the
database for transactions, we use sequences for all primary keys (we
have to support databases that do not have SERIAL or AUTOINCREMENT
columns, and we have many use cases where we need to know the IDs
before we do our insert). We don't need or want to cache anything.
Our current database layer is very similar to the basic Table objects
in SQLAlchemy, and we use those to do all of our CRUD operations
against our tables.
I think there are people out there who really want something like this:
1. Transactions are entirely managed through the database. When
you start a transaction, it immediately issues a "BEGIN"
against your connection.
2. All SQL is emitted immediately, not buffered up and issued when
you commit. (This is needed also to support the above).
3. Any errors result in a "ROLLBACK" against the connection.
4. No caching of objects. This can be done in a different layer
if needed.
5. You can use table objects directly in the same transaction as
mapped objects, with no ill effects. Table operations will
also immediately emit SQL to the connection.
I think Aaron's simple object layer is trying to address this in
part, but it would be great if we didn't have to have two entirely
different object layers in SQLAlchemy. It seems more ideal to have
one basic layer that can behave either way, depending on your
applications' needs.
Not sure how you feel about this though...
--
Jonathan LaCour
http://cleverdevil.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
