Torsten Landschoff wrote: > > Thanks for your reply and the remarks! Do you plan to extend > attribute_mapped_collection to update the key like in my example?
here's some things to note on that: 1. I'm not sure why it wasn't that way already, and I'd want to hear from Jason Kirtland, its author, on if we are missing something or otherwise whats up. I have a vague notion that there was a reason for this, or maybe not. 2. I wonder if there's a way to make this happen more deeply than within setattr(). Like the collection internals would include an event to operate upon the target object that includes the other args from the collection decorator. 3. corresponding delete() event. Set the attribute on the replaced object to None ? that seems potentially surprising ? > Be aware that this approach also has it's downside. For example, > assigning > > item2 = Item() > item2.notes['color'] = item.notes['color'] > > will not work contrary to what one might expect (it generated a conflict > on the id column). The solution is to have the target collection copy > the assigned object if it has a key already. But that might be too much > magic to be easy to understand. the target can only be in one collection at a time so I would think item2's id wins. its a primary key switch. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
