yeah SQLAlchemy started, like Rick was getting at, with a much closer
to the metal idea than that, that if you made a new object and put it
in the session, youd know that it wasnt flushed yet. My experience
with hibernate is identical, actually, nothing gets generated or
anything in
On Dec 12, 2007, at 4:49 PM, Adam Batkin wrote:
I would think it could be an option on the Table (err, Column) itself
and not a mapper option. Something like pending_flush=True (which can
default to False to keep the current behavior...though that name
probably isn't very good, but
Rick Morrison wrote:
Wouldn't a flavor of .save() that always flush()'ed work for this case?
say, Session.persist(obj)
Which would then chase down the relational references and persist the
object graph of that object...and then add the now-persisted object to
the identity map.
But another thing, is that the whole idea of save/update/save-or-
update, which we obviously got from hibernate, is something ive been
considering ditching, in favor of something more oriented towards a
container like add(). since i think even hibernate's original idea
of save/update has
On Dec 9, 2007, at 4:10 PM, Adam Batkin wrote:
If I create an object, then save() it, potentially the object won't be
actually persisted until sqlalchemy decides that it needs to (for
example on flush/commit, or when some query involving Thing's table
gets
executed) which is good. But
My thought is that sqlalchemy should force the object to be flushed
(or
whatever must be done to determine the ID, possibly just selecting the
next value from a sequence) when the id property is retrieved.
can't be done for mysql, sqlite, MSSQL, others, without issuing an
INSERT.
On Dec 9, 2007, at 4:57 PM, Adam Batkin wrote:
Ahh, but session.save() was already called, so trying to fetch a
database-generated attribute (such as the primary key in my case)
should
trigger a flush of the row itself. That can be done with any database.
It wouldn't be done on __init__,
I hate to disagree here, and I can see what you're getting at, but
honestly, the INSERT on save() approach is exactly the naive active-
record-like pattern that SQLAlchemy's ORM was designed to get away from.
The way the unit of work functions, we dont generate ids until a flush
