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
-~----------~----~----~----~------~----~------~--~---

Reply via email to