On Jul 31, 2007, at 7:14 AM, Wojciech Smigaj wrote:
> I get the following error:
>
> Traceback (most recent call last):
> File "test_case.py", line 34, in ?
> session.merge(obj)
> File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/
> sqlalchemy/orm/session.py", line 501, in merge
> raise exceptions.AssertionError("Instance %s has an instance key
> but is not persisted" % mapperutil.instance_str(object))
> NameError: global name 'mapperutil' is not defined
>
OK theres two errors there, one is our AssertionError is using an
unimported library, so thats a bug. but the error is that the object
youre giving it has an _instance_key but is not persisted in the
DB..thats because youve already deleted it. its actually looking in
the database for your item and not finding it. If you have flushed a
deleted object, its gone; you can either remove _instance_key from
your deleted object and save() it again, or make a totally new object
and save().
> I have also tried the update() method, but apparently in this case it
> doesn't do anything (no SQL code is produced) so that the second
> delete() call fails, as the code is trying to delete an already
> deleted object. Actually, it's not clear to me in what state the
> delete() method leaves the object: I thought it was "detached", but
> then I suppose the update() method should work...
well update() is probably confused since it does not check the
database to see if the object exists...that would be excessive. but
then, yes that will break because its going to try and UPDATE a row
that does not exist.
if you deleted and object and then flushed, its gone from the DB, and
your actual instance, which youre supposed to throw away, looks to
the Session more or less like a persisted object if you try to put it
back in since it still has the _instance_key attached to it. We cant
necessarily assume, on the SA side, that we can just remove
_instance_key; the object also has its primary key identifiers
attached to it. its not clear if those identifiers should be cleared
out or not, assuming a new INSERT operation...we dont track if they
were auto-generated or if they were programmatically set, or what
effects it would have if those identifiers were re-INSERTed or what.
The usual pattern for "undoable operations" would proceed entirely
before any data is actually persisted to the database; i.e. the delete
() operation should be considered permanent, unless you are planning
on using a transaction ROLLBACK as your "undo".
>
> By the way, it looks that there's a bug in the session.py file: the
> "from sqlalchemy.orm import util as mapperutil" line is missing.
indeed, this bug is fixed in 0.4 trunk.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
