I have talked to my customers, and they agreed that your solution is great. To match their demands, I've changed two things: 1. If the object exists in the db during construction than it's returned, else the object returned is a new object (that isn't returned). 2. All the attributes that identifies the object, are read-only, so I don't have to worry about them changing the "identity" of the object (Which may cause an unpredicted behaviour)
SO THANKSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS! On 4 דצמבר, 03:59, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Dec 3, 2008, at 6:39 PM, [EMAIL PROTECTED] wrote: > > > > > B. So I can settle with a merge() method that returns anobject. I > > think it's the only solution (beside forcing them to work with saving > > to the db). Actually, it's not too bad. But it's also not easy, I tell > > you, to write such a function. Because what happens if one of the > > things that defines me, a part of my uniqueness, is not really a > > unique field, but a list of objects that are connected to me in a > > many- > > to-many relationship from another table. And what if I need to call > > merge() on each one of them. And what if two of them are evaluated to > > be the sameobject, so I need to fix the list. oof! > > merge() doesn't do much that you couldn't do manually on your own. > if you need to write a jacked up merge()-like function that compares > collections and things, i dont think Python will let you down in that > regard. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---