On 1/4/07, Michael Bayer [EMAIL PROTECTED] wrote:
Arnar Birgisson wrote:
On 1/3/07, Michael Bayer [EMAIL PROTECTED] wrote:
yeah that would be why. SA's ORM has no ability to update primary key
columns from their original valueyoull have to update it yourself,
or copy the object instance to a new one, etc. (or not make that col a
primary key)
Ok thanks. Is there something fundamental in SA architecture that
prevents updating of primary keys - or is it simply not implemented
b/c it's complicated/difficult?
its something fundamental, i.e. the identity map:
http://www.sqlalchemy.org/trac/wiki/FAQ#asingleobjectsprimarykeycanchangecanSAsORMhandleit
adding code to update the column, and switch the identity of an entity,
is not impossible. im not sure at this moment how involved it is, i
have a feeling it will start out easy but then branch off into lots of
unforseen ill effects that I cant predict at the moment. mostly, im
just not sure if the ORM should really be taking on the task of
changing the identity of entities in-session.
Sounds reasonable that development is focused elsewhere then :o) - I
just wish I had more time so that I could be more involved.
In any case, if SA can't update primary keys I'd expect it to blow up
in my face if I tried doing that. Instead it just silently flushed the
uow session without making any updates - leaving the model in
inconsistent state with the database. Shouldn't there be some kind of
error?
initially i hadnt made my mind up about that, since i dont want to get
in the way of schemes that the user might be plotting, such as doing
something in a MapperExtension.after_update() step. however i have a
feeling that nobody is doing that sort of thing, so i can look into
adding this check (ticket 412).
Right, I hadn't thought of that.
Yesterday I had to write a one-time script that change the
identities of a bunch (~200k) records and their two kinds of children.
I did this by selecting up the objects via the ORM model to prepare
what I had to do, then I cleared the session and made the updates
directly with on the engine (bypassing the ORM). Now it seems (b/c
other people keep changing specs) that I have to do something similar
again.
Now, what I really wanted to do is to write a method on my class that
takes care of changing it's primary key (or part of it, at least) and
cascade the change down to the children of that entity. Would that be
possible while keeping the process transparent to the caller, as far
as removing the object from the identity map and re-adding it with the
new key. I'm sorry if it sounds stupid, I don't have a full
understanding of the identity map.
I.e. I would like to do something like this:
obj = session.query(TheClass).get('pk-before')
# obj has child relationships, some lazy-loaded and others eager-loaded
obj.rename('pk-after')
# session.flush() - I can live with having to do this here.
obj2 = session.query(TheClass).get('pk-after')
assert obj == obj2
I'm not asking for a solution, just an indicator if this is possible
and some pointers on how you would do it in general, then I'd be able
to figure out the details.
Arnar
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
