On Jan 5, 2009, at 3:49 PM, arn vollebregt wrote:
> > But isn't the identity comprised of the object class and the primary > key? > Would that not make the Foo instances the same in the eyes of > SQLAlchemy? Or > am I perhaps confusing the id variable with the real primary key > which is > stored somewhere else? it is. but this identity is not assigned until after the INSERT occurs. > Oeh yes, that works quite good! You whipped that out quite fast :) > Clean > code as well! > Is this declarative approach the only option, or is that just what you > happen to prefer? I am trying to keep my database/SQLAlchemy 'layer' > separated from my object declarations in my code, hence the question. its just using column_property() which is like anything else you send to mapper(... properties={}). Just pull the column within from the mapped table. > Right, next stop for me is writing an add_or_merge() function which > tries to > add an object to the session, and returns an existing object when a > UniqueConstraintException is raised. Sounds like a challenge when > relations > and association_proxy's come into play :) it does. merge() doesn't have those kinds of hooks. I'd consider using a creational pattern to return the unique object instead, i.e. such as a specialized __new__: x = MyInstance(session, foo=1, bar=2) class MyInstance(object): def __new__(cls, session, foo, bar): if <check the session for foo, bar>: return <my unique map>[(foo, bar)] else: return object.__new__(cls) --~--~---------~--~----~------------~-------~--~----~ 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 sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---