I have found that this specific behaviour (re-initialization of the
InstrumentedList) does not happen if "expire_on_commit = False" is set
on the sesssion. However this leads to other errors in my code.
I guess I don't quite understand why expire would be called after a
commit; shouldn't the commit result in the session being perfectly
synchronized with the DB?
On Mar 29, 12:48 pm, lars van gemerden <l...@rational-it.com> wrote:
> I think I have an odd case of the first possibility you mentioned:
>
> I am generating XML from SAclass objects opdating these objects from
> XML. To detect cyclic references and double objects, I maintain a
> registry of objects based on id() (reg[str(id(obj))] = obj). The id is
> stored as the attribute "ID" in the XML tag. When updating the objects
> I first look them up in the registry obj = reg[etree.get("ID")] and
> update them afterwards. I do this as well with relationships/
> InstrumentedLists (but not with database fields like Integer).
>
> What I noticed was that InstrumentedList changes id() after a commit
> (with a = Address(), Address.persons = relationship(...) ):
>
> print id(a), id(a.persons), id(a.persons[0])
> session.commit()
> print id(a), id(a.persons), id(a.persons[0])
>
> gives:
>
> 47148168 47174264 47114112
> 47148168 47175784 47114112 (the middle id has changed)
>
> So I assume that after a commit a new InstrumentedList is created.
>
> - Could it be conceivable that is causes the warning mentioned
> above(an old version of the InstrumentedList being updated with an
> valid SAclass object)?
> - Is there a way to get around this new INstrumetnedList being
> created?
>
> Cheers, Lars
>
> On Mar 29, 1:53 am, Michael Bayer <mike...@zzzcomputing.com> wrote:
>
>
>
>
>
>
>
> > you've got a situation like this:
>
> > ft = session.query(FieldType).first()
>
> > f = Field()
> > ft.of_members.append(f)
>
> > assert f in session # normally returns True, assuming normal cascade on
> > "of_members"
>
> > session.expunge(f) # remove f from the session
>
> > session.flush() # generates warning, since ft.of_members has changed but
> > the contents aren't in the Session
>
> > Another cause could be, "of_members" has a cascade that doesn't include
> > save-update, like "cascade='delete'" is a common mistake.
>
> > On Mar 28, 2012, at 6:45 PM, lars van gemerden wrote:
>
> > > Hi all,
>
> > > I am getting the error: "SAWarning: Object of type <Field> not in
> > > session, add operation along 'FieldType.of_members' will not proceed"
> > > and have no idea where to start looking for the error. Can anyone help
> > > me with some idea of why this warning occurs or what direction to look
> > > in order to fix it?
>
> > > The warning occurs only during the first call of a specific method,
> > > while i think i reset everything (e.g. dropping all tables in the
> > > database) between calls.
>
> > > Cheers, Lars
>
> > > --
> > > 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
> > > athttp://groups.google.com/group/sqlalchemy?hl=en.
--
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.
