Michael Bayer wrote:
On Apr 6, 2006, at 3:41 PM, dmiller wrote:
Does this mean I don't need to use mapper.using(...).select(...) to
execute a query on a session anymore? i.e. I could do
mapper.select(session=x, ...)
oh...well, I actually just committed the big change, since after
you generally shouldnt store any information in a primary key. primary
keys are by definition immutable so SA would likely trip up if you change
them. its conceivable that a feature could be added to allow updating the
primary key columns but it would add a lot of complexity to the saving
because the join condition is on two primary key columns, the fact that
they are primary keys is overriding the fact that one of them is a foreign
key and its determining the direction of the relationship improperly.
if you give it a clue as to which side of the join is the foreignkey
like this,
its in the __del__ method of ConnectionFairy in pool.py, which can be
propigated out to whatever other connection-holding object there is (such
as this one i am still coming up with). so del connection is how to
force the reference count down to zero. but if jython isnt going to work
On 7 Apr 2006 at 19:00, Michael Bayer wrote:
the moral of the story is, if del object takes the reference count
down to zero, but Jython is still not going to call __del__ despite
this, then the connection pooling in SA needs some major changes to
explicitly count checkouts within the same
5 matches
Mail list logo
