[sqlalchemy] Hey, try out Flock
Hello,I'm emailing you about Flock. I'm now using Flock as my default browser, and I love what it's done for my whole Web experience. Flock is a social web browser that uniquely pulls together the people, photos, videos and websites I care about. Check it out, I think you're really going to like it.You can download it for free at http://www.flock.com/invited/1209451183 Enjoy it! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Concrete inheritance woes
On Mon, Apr 28, 2008 at 10:33 PM, Michael Bayer
[EMAIL PROTECTED] wrote:
pjoin = polymorphic_union(...)
pjoin2 = polymorphic_union(...)
employee_mapper = mapper(Employee, pjoin, polymorphic_on=pjoin.c.type)
manager_mapper = mapper(Manager, managers_table,
inherits=employee_mapper, concrete=True, polymorphic_identity='manager')
engineer_mapper = mapper(Engineer, engineers_table,
with_polymorphic=('*', pjoin2),
polymorphic_on=pjoin2.c.type,
inherits=employee_mapper, concrete=True,
polymorphic_identity='engineer')
hacker_mapper = mapper(Hacker, hackers_table, inherits=engineer_mapper,
concrete=True, polymorphic_identity='hacker')
This solves nicely my multi-level problem, thanks !
this should in theory also fix the engineers relation on Company.
Doesn't seem to. Since I guess it's a bug, I've filed ticket 1018 for this.
http://www.sqlalchemy.org/trac/ticket/1018
But as I've said many times (to svil, at least) concrete inheritance
is something i havent gotten into much as of yet, largely due to the
many inherent issues with it as well as its being a generally
unpopular pattern, so there may still be issues with this setup (but
let me know, since thats how it should work).
Ok, no worries.
In any case the unit tests which you were working from (im guessing
test/orm/inheritance/concrete.py) should be patched to include this
test (i.e. including Hacker, the polymorphic load, as well as the
relation).
I'll add the working multi-level test this afternoon. I guess you
don't want the relation part yet.
Assuming it works we should also make sure the 0.5 branch
(which isnt called that yet) can handle it too.
--
Gaëtan de Menten
http://openhex.org
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Concrete inheritance woes
On Tue, Apr 29, 2008 at 12:11 PM, Gaetan de Menten [EMAIL PROTECTED] wrote: On Mon, Apr 28, 2008 at 10:33 PM, Michael Bayer [EMAIL PROTECTED] wrote: In any case the unit tests which you were working from (im guessing test/orm/inheritance/concrete.py) should be patched to include this test (i.e. including Hacker, the polymorphic load, as well as the relation). I'll add the working multi-level test this afternoon. Done. -- Gaëtan de Menten http://openhex.org --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] association proxy error: stale association proxy
The following code duplicates a situation I'm seeing with the
association proxy. There are at least two ways I can avoid having the
error happen. But since I wasn't sure if the error is a usage error,
I wanted to post here first before implementing my work around. One
work around for the test code is to delete/comment out line 77
(commented as such).
Here is the traceback of the error (run against r4588):
Traceback (most recent call last):
File atest.py, line 82, in module
have_a_kid('A', 'b') # fails with 'stale association proxy...'
File atest.py, line 34, in have_a_kid
if k.kid_name not in [kk.kid_name for kk in p.kids]:
File /home/sim/en36219/.python/sqlalchemy/ext/associationproxy.py,
line 353, in __iter__
for member in self.col:
File /home/sim/en36219/.python/sqlalchemy/ext/associationproxy.py,
line 271, in lambda
col = property(lambda self: self.lazy_collection())
File /home/sim/en36219/.python/sqlalchemy/ext/associationproxy.py,
line 140, in lazy_collection
stale association proxy, parent object has gone out of
sqlalchemy.exceptions.InvalidRequestError: stale association proxy,
parent object has gone out of scope
Here is the code:
from sqlalchemy.ext.associationproxy import association_proxy
from sqlalchemy import (
create_engine, MetaData, Table, Column, Integer, String,
ForeignKey)
from sqlalchemy.orm import mapper, relation, create_session
class Parent(object):
kids = association_proxy('kid_associations', 'kid',
creator=lambda x,**kw: Parent_x_Kid(x, **kw))
def __init__(self, name):
self.parent_name = name
def __repr__(self):
return 'Parent(%s)' % self.parent_name
class Kid(object):
parents = association_proxy('parent_associations', 'parent',
creator=lambda x,**kw: Parent_x_Kid(x, **kw))
def __init__(self, name):
self.kid_name = name
def __repr__(self):
return 'Kid(%s)' % self.kid_name
class Parent_x_Kid(object):
def __init__(self, kid):
self.kid = kid
def __repr__(self):
return 'PK(%s,%s)' % (self.parent.parent_name,
self.kid.kid_name)
def have_a_kid(p_name, k_name):
p = session.query(Parent).filter_by(parent_name = p_name).one()
k = session.query(Kid).filter_by(kid_name = k_name).one()
if k.kid_name not in [kk.kid_name for kk in p.kids]:
p.kids.append(k)
else:
print %s already has a %s % (p, k)
db_con = create_engine('sqlite:///:memory:')
metadata = MetaData(db_con)
# TABLE CREATION
parents = Table('parents', metadata,
Column('parent_id', Integer, primary_key=True),
Column('parent_name', String(30), nullable=False)
)
kids = Table('kids', metadata,
Column('kid_id', Integer, primary_key=True),
Column('kid_name', String(30), nullable=False)
)
parent_x_kid = Table('parent_x_kid', metadata,
Column('parent_id', Integer, ForeignKey('parents.parent_id'),
primary_key=True),
Column('kid_id', Integer, ForeignKey('kids.kid_id'),
primary_key=True),
)
metadata.create_all()
# MAPPERS
mapper(Parent_x_Kid, parent_x_kid, properties={
'parent':relation(Parent, lazy=False),
'kid':relation(Kid, lazy=False)
})
mapper(Parent, parents, properties={
'kid_associations':relation(
Parent_x_Kid, cascade='all, delete-orphan', lazy=True)
})
mapper(Kid, kids, properties={
'parent_associations':relation(
Parent_x_Kid, cascade='all, delete-orphan', lazy=True)
})
session = create_session()
# TEST DATA CREATION
p_s = [Parent('A'), Parent('B'), Parent('C'), Parent('D')]
k_s = [Kid('a'), Kid('b'), Kid('c'), Kid('d'), Kid('e')]
[session.save(x) for x in p_s]
[session.save(x) for x in k_s]
session.flush()
session.clear() # LINE 77, delete to make this code work
have_a_kid('A', 'a')
have_a_kid('B', 'b')
have_a_kid('C', 'b')
have_a_kid('D', 'c')
have_a_kid('A', 'b') # fails with 'stale association proxy...'
have_a_kid('A', 'c')
have_a_kid('B', 'c')
have_a_kid('A', 'e')
session.flush()
# PRINTING TEST DATA
session.clear()
pA = session.query(Parent).filter_by(parent_name = 'A').one()
print pA
print , pA.kids
pB = session.query(Parent).filter_by(parent_name = 'B').one()
print pB
print , pB.kids
ka = session.query(Kid).filter_by(kid_name = 'a').one()
print ka
print , ka.parents
kb = session.query(Kid).filter_by(kid_name = 'b').one()
print kb
print , kb.parents
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: association proxy error: stale association proxy
I understand why I'm seeing the error. But should the user really be required to keep the parent around in a variable? I would have thought that the session would be tracking each successive changes. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: association proxy error: stale association proxy
Paul K wrote:
The following code duplicates a situation I'm seeing with the
association proxy. There are at least two ways I can avoid having the
error happen. But since I wasn't sure if the error is a usage error,
I wanted to post here first before implementing my work around. One
work around for the test code is to delete/comment out line 77
(commented as such).
I understand why I'm seeing the error. But should the user really be
required to keep the parent around in a variable? I would have
thought that the session would be tracking each successive changes.
This is fixed in the trunk @ r4593. The issue was in association
proxy's handling of a stale cache attribute it stashes on instances and
was fundamentally:
p_copy = copy.copy(parent)
del parent
p_copy.kids.append(a_kid) # previously, boom
That's similar to what was going under the orm hood with the modified
instances coming in and out of scope in have_a_kid.
The patch in the trunk is pretty small, but if that's not an option you
can work around the issue somewhat painfully by removing the cache
attribute from instances:
for attr in dir(p_copy):
if attr.startswith('_AssociationProxy_kid_associations_'):
delattr(p_copy, attr)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Concrete inheritance woes
g'day Gaetan u could try my tests and play with DB_inheritance=concrete to see my experience so far with dbcook (not documented i know but works4me) and its tests. also u can look up the mailgroup history for my own concrete-related complaints... most of them have hit unimplemented parts of SA so they stopped there. codewise, see mapcontext.py and mapper-stuff in builder.py. Most of logic is about whether an object is being split into tables (joined) or not (concrete). i also have mixed inheritance (parts of the hierarchy this way, part another, then again), but thats even further the track. IMO should work once the pure concrete is ok. btw did u get single inh to work 100%? i didnt bother to finish it... no time/usecase. i guess some of the things might have cleared since recent introduction of with_polymorphic, but i havent tried really... dbcook is still using select_table so needs some rework. hmm as i see current SA trunk does not work now with exactly some concrete tests, and some other issues of me using under-cover things. as a rough guess, v4300 seems to work. ./dbcook/tests$ make abc will do all inheritances, AB only, ~200 cases, no C-level. ok on v4300; 3 fails (inh=c) on recent trunk ./dbcook/tests$ make abcj will do joined inh, A+B+C, ~6000 cases. ok on v4300; ok on trunk ./dbcook/tests$ make abc ARGS=doC inhs=c will run concrete inh, ~6000 cases... as i see 24% fail at v4300. IMO most of these are the below adressing-related ./dbcook/tests$ make abc ARGS=doC will run everything, ~14000 cases, ~1/2 hour things i remember right now (long time havent looked into that) - for proper addresing, primary key has to be somehow id+type; otherwise there is A with id=1 and also B with id=1 and C and... so cannot singly-reference an object. - all relations and some others (e.g. post_update in my case) has to be manualy inherited (=copied) - since day 1 i tried it. at certain time there were more issues around it. - *-to-many relations are terra-incognita, as they combine polymorphism with addressing... - once A,B,C works, try A,B,C,D in a case or two, all levels should have instances (A too!). only that covers it all (base + 2 levels + leaf, thats two overlapping 3-levels. uncovers SA logic at different angles) btw, if Mike is about delving into all this now, i think i have some time to look around it, at least move onto with_polymorphic. ciao svil On Monday 28 April 2008 19:07:51 Gaetan de Menten wrote: Hi there, I've been playing with concrete inheritance a bit these days (trying to implement it into Elixir). I've run into several problems, which might be known limitations, but I'd like to know for sure or be shown what I've done wrong... The two problems I get involve a chain of classes inheriting from one another: class C inherits from class B which inherits from class A. The first problem is that I can get a polymorphic load starting from class B. I'd like it to return instances of class C, along with the instances from class B. Querying class A works as expected though (return instances of A, B and C). See multi_level_concrete.py for what I tried. (It's a hacked/standalone version of the unit tests found in SA itself). FWIW, I run them with nosetest. The second (probably related) problem is that I can't get relationships to work polymorphically. I'd like to have a relationship to the B class. Since I've read in the doc that the relation is not inherited automatically, I tried duplicating manually, but then it doesn't work polymorphically... Anyway, see concrete_with_relations.py for my experimentations. Thanks in advance for any pointer on this, --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Concrete inheritance woes
On Apr 29, 2008, at 2:32 PM, [EMAIL PROTECTED] wrote: btw, if Mike is about delving into all this now, i think i have some time to look around it, at least move onto with_polymorphic. if you're going to deal with future functionality, go work with the user_defined_state branch for now, which will soon be merged to trunk as 0.5. The internals of with_polymorphic are again highly modified there. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: association proxy error: stale association proxy
Thanks. That fixed what I was seeing.
Paul Kippes
On Apr 29, 1:49 pm, jason kirtland [EMAIL PROTECTED] wrote:
Paul K wrote:
The following code duplicates a situation I'm seeing with the
association proxy. There are at least two ways I can avoid having the
error happen. But since I wasn't sure if the error is a usage error,
I wanted to post here first before implementing my work around. One
work around for the test code is to delete/comment out line 77
(commented as such).
I understand why I'm seeing the error. But should the user really be
required to keep the parent around in a variable? I would have
thought that the session would be tracking each successive changes.
This is fixed in the trunk @ r4593. The issue was in association
proxy's handling of a stale cache attribute it stashes on instances and
was fundamentally:
p_copy = copy.copy(parent)
del parent
p_copy.kids.append(a_kid) # previously, boom
That's similar to what was going under the orm hood with the modified
instances coming in and out of scope in have_a_kid.
The patch in the trunk is pretty small, but if that's not an option you
can work around the issue somewhat painfully by removing the cache
attribute from instances:
for attr in dir(p_copy):
if attr.startswith('_AssociationProxy_kid_associations_'):
delattr(p_copy, attr)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] is MapperExtension.after_update() called before the UPDATE is issued to the DB?
Hi, I'm trying to write a mapper extension that notifies a daemon about changes made to the DB that it needs to care about. But it looks like after_update() is actually getting called before the UPDATE is sent to the db. Not knowing a better way to debug it, I just threw a pdb.set_trace() into my after_update method to pause the process making the change, then queried the db directly using sql. It looks like the change hasn't made it to the DB yet, even though pdb.set_trace() is being triggered. I'm using 0.4.3, with psycopg2. Is this a known bug? Or am I just using the MapperExtension incorrectly? Any help would be greatly appreciated. Thanks. -- david bonner [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: subquery and inheritance
If I add a simple correlate feature to Query in 0.5, you can use the raw Table object to bypass the ORM meaning of Dataset and Base. the query above is not quite complete but I can get an approximation like this: Is this functionality available currently or am I waiting for sqlalchemy 0.5? If I try the above constructs I am getting AttributeError: 'PGCompiler' object has no attribute 'mapped_table' So I think going forward, the concept of use the Table objects directly when you want to bypass the higher level meaning of Dataset.id, i.e. that its selecting from a join of Dataset and Base, might be a good way to go with this. Is there a branch (or trunk) that I should be using Thanks, Kris --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
