also, can someone explain what is the difference (sql-plan-wise) in
the approaches?
this one is:
address ->
addressable
<- users
<- orders
my one is otherway around:
address <-
addressable
-> users
-> orders
both declare multiple (per-type) relations/backrefs on the
intermediate adressable - just 1-to-many vs many-to-1.
this puts foregnkeys into the ends, why my one puts foregnkeys on the
adressable.
On Thursday 03 July 2008 19:36:12 Gaetan de Menten wrote:
> On Thu, Jul 3, 2008 at 6:01 PM, <[EMAIL PROTECTED]> wrote:
> > On Thursday 03 July 2008 17:15:40 Michael Bayer wrote:
> >> the first set of operations on the Session place every new
> >> object, including two Address objects and two GenericAssoc
> >> objects, in the session. Then the session is cleared. Then, a
> >> series of loads load in all those same objects, including the
> >> same Address objects and GenericAssoc objects, except different
> >> instances of them local to that session (since the previous were
> >> cleared). Then, when u2 = User() is created and is associated
> >> with "a2" from the *first* session, the two original
> >> GenericAssoc objects (which were cleared) now become associated
> >> with that User object via the connection to Address, which fail
> >> to be added since there are already two GenericAssoc's from the
> >> second Session usage present.
>
> Jeeez. I hate myself for thinking it was some complex thing related
> to the pattern used and not even looking further...
>
> > ahh yes i had this same a week ago but i forgot.
> > so is u2=session.merge(u2) a cure?
> > i used it on some similar (test) case
>
> a2 = sess.merge(a2) is a cure indeed.
>
> >> On Jul 3, 2008, at 9:31 AM, Gaetan de Menten wrote:
> >> > Hi list,
> >> >
> >> > Could anybody tell me what's wrong with the following code?
> >> > It's only the code in the poly_assoc example directory (the
> >> > generic version) where I'm trying to set the polymorphic part
> >> > of the relationship. It gets me the traceback below and I
> >> > don't really understand why:
> >> >
> >> > Traceback (most recent call last):
> >> > File "poly_assoc_3.py", line 155, in <module>
> >> > sess.save(u2)
> >> > File
> >> > "/home/ged/devel/sqlalchemy/trunk/lib/sqlalchemy/util.py",
> >> > line 1550, in func_with_warning
> >> > return func(*args, **kwargs)
> >> > File "/home/ged/devel/sqlalchemy/trunk/lib/sqlalchemy/orm/
> >> > session.py",
> >> > line 1055, in save
> >> > self._cascade_save_or_update(state, entity_name)
> >> > File "/home/ged/devel/sqlalchemy/trunk/lib/sqlalchemy/orm/
> >> > session.py",
> >> > line 1111, in _cascade_save_or_update
> >> > self._save_or_update_impl(state)
> >> > File "/home/ged/devel/sqlalchemy/trunk/lib/sqlalchemy/orm/
> >> > session.py",
> >> > line 1251, in _save_or_update_impl
> >> > self._update_impl(state)
> >> > File "/home/ged/devel/sqlalchemy/trunk/lib/sqlalchemy/orm/
> >> > session.py",
> >> > line 1241, in _update_impl
> >> > "session." % (mapperutil.state_str(state), state.key))
> >> > sqlalchemy.exc.InvalidRequestError: Could not update instance
> >> > '[EMAIL PROTECTED]', identity key (<class
> >> > '__main__.GenericAssoc'>, (1,), None); a different instance
> >> > with the same identity key already exists in this session.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
