[sqlalchemy] Re: cascade='all, delete-orphan' causing error about unsaved, pending instances

2007-05-17 Thread Glauco
http://www.sqlalchemy.org/trac/wiki/ FAQ#FlushError:instancesomeinstanceisanunsavedpendinginstanceandisanorph an I think this is not Andreas an I too are searching to explain. The documentation is correct, and infact in tg-admin all go perfeclty.. but when the same example is gone from TG

[sqlalchemy] Re: cascade='all, delete-orphan' causing error about unsaved, pending instances

2007-05-17 Thread Andreas Jung
--On 16. Mai 2007 13:45:21 -0400 Michael Bayer [EMAIL PROTECTED] wrote: new to the FAQ: http://www.sqlalchemy.org/trac/wiki/ FAQ#FlushError:instancesomeinstanceisanunsavedpendinginstanceandisanorph an The FAQ does not explain the problem. Look at the real code: def

[sqlalchemy] Re: Problem with using global metadata/connection in a threaded context

2007-05-17 Thread Andreas Jung
--On 17. Mai 2007 00:28:35 +0200 David Anderson [EMAIL PROTECTED] wrote: I am guessing that somewhere in the mix the engine information is severed from the metadata when jumping to the other thread, but I have no idea how to fix this problem. Can anyone give me pointers on how to get my

[sqlalchemy] Re: cascade='all, delete-orphan' causing error about unsaved, pending instances

2007-05-17 Thread Andreas Jung
--On 17. Mai 2007 10:16:17 +0200 Andreas Jung [EMAIL PROTECTED] wrote: --On 16. Mai 2007 13:45:21 -0400 Michael Bayer [EMAIL PROTECTED] wrote: This code causes the trouble. There is no save() operation involved - just a flush() operation driven by the Zope transaction integration of SA.

[sqlalchemy] Re: cascade='all, delete-orphan' causing error about unsaved, pending instances

2007-05-17 Thread Michael Bayer
On May 17, 2007, at 4:16 AM, Andreas Jung wrote: The FAQ does not explain the problem. Look at the real code: def importImagesFromFilesystem(self, lidx, imgdir): Import all images from a local filesystem into the staging area of the Medium. # get

[sqlalchemy] Re: Many to many: No column ... is configured on mapper (since 0.3.7)

2007-05-17 Thread Michael Bayer
On May 17, 2007, at 9:03 AM, David Leuschner wrote: Hi, since the 0.3.7 release a great feature of many to many relationships disappeared. The following code refers to the Wiki example for many to many relationships. With 0.3.6 I could either write this is a bug that was introduced in

[sqlalchemy] Re: Many to many: No column ... is configured on mapper (since 0.3.7)

2007-05-17 Thread David Leuschner
this is a bug that was introduced in r2556, where an optimization to the SQL used to query the remote table was not properly accounting for a many-to-many join criterion, fixed in rev 2625. Thanks for the fast response! I've just found the new entry in the Changelog and am looking forward to

[sqlalchemy] joining 3 tables together

2007-05-17 Thread Victor Ng
I'm struggling to join 3 tables together and I can't seem to figure out the correct syntax to do this: I have 3 classes that are laid out like this: 6 class Bar(Entity): 7 has_field('col_a', Integer(), unique=True) 8 using_options(tablename='bar') 9 10 class Blah(Entity): 11

[sqlalchemy] Re: joining 3 tables together

2007-05-17 Thread Victor Ng
Sorry - I meant to post this to the elixir group. vic On May 17, 3:56 pm, Victor Ng [EMAIL PROTECTED] wrote: I'm struggling to join 3 tables together and I can't seem to figure out the correct syntax to do this: I have 3 classes that are laid out like this: 6 class Bar(Entity): 7

[sqlalchemy] Modifying __dict__ doesn't dirty an instance

2007-05-17 Thread Catherine
I noticed an issue that - well, I honestly don't know whether to call it a bug or not. I need to talk it out with somebody who understands SQLA better. When I retrieve an instance, then alter its attributes by manipulating its __dict__, the instance doesn't get dirtied, and the changes won't be

[sqlalchemy] Re: Modifying __dict__ doesn't dirty an instance

2007-05-17 Thread Michael Bayer
On May 17, 2007, at 5:31 PM, Catherine wrote: I noticed an issue that - well, I honestly don't know whether to call it a bug or not. I need to talk it out with somebody who understands SQLA better. When I retrieve an instance, then alter its attributes by manipulating its __dict__, the

[sqlalchemy] Re: Modifying __dict__ doesn't dirty an instance

2007-05-17 Thread Barry Hart
Note that not all object 'fields' are present in the dictionary. For example, in our app we may have a SQLAlchemy property '_foo' which is exposed as a Python property 'foo'. In this case I believe '_foo' will be in the dictionary, but your app should probably be working with 'foo'. Barry