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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
