[sqlalchemy] Re: Polymorphic concrete inheritance question
On Dec 3, 2008, at 5:15 PM, [EMAIL PROTECTED] wrote:
>
> On Wednesday 03 December 2008 23:28:01 Michael Bayer wrote:
>> On Dec 3, 2008, at 3:45 PM, [EMAIL PROTECTED] wrote:
>>> okay, then i get this as answer to my other question - so
>>> concrete polymorhism relations/get()/identity on top of it are
>>> blue_sky. that's okay - just put a line about it in the docs.
>>> dbcook is throwing warnings about it since long time.
>>
>> modify your code to use the query.with_polymorphic('*', selectable,
>> some_discriminator_column) approach in r5413, and then tell me what
>> issues remain.
>
> u mean a plain mapper without polymorphism, then above
> query().with_poly? that seem to work.
> but it still needs .filter(
> discriminator==identity) for a get()-like op to work.
no, you say session.query(cls).get(x) - you're looking for class
"cls". get() is not going to figure that out for you. I think
concrete inheritance is more useful when its less magical.
> and in this case each query() will also needs the .with_poly(..)
> stuff, so whole automatics (specifying things once) gets lost.
if you want polymorphic loading. Which you usually shouldn't, if you
are using concrete inheritance. it is not optimized for that.
> ah, forget it. i dont need concrete without working relations, just
> played with the tests.
there we go !
--~--~-~--~~~---~--~~
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: Polymorphic concrete inheritance question
On Wednesday 03 December 2008 23:28:01 Michael Bayer wrote:
> On Dec 3, 2008, at 3:45 PM, [EMAIL PROTECTED] wrote:
> > okay, then i get this as answer to my other question - so
> > concrete polymorhism relations/get()/identity on top of it are
> > blue_sky. that's okay - just put a line about it in the docs.
> > dbcook is throwing warnings about it since long time.
>
> modify your code to use the query.with_polymorphic('*', selectable,
> some_discriminator_column) approach in r5413, and then tell me what
> issues remain.
u mean a plain mapper without polymorphism, then above
query().with_poly? that seem to work.
but it still needs .filter(
discriminator==identity) for a get()-like op to work.
and in this case each query() will also needs the .with_poly(..)
stuff, so whole automatics (specifying things once) gets lost.
ah, forget it. i dont need concrete without working relations, just
played with the tests.
if u decide one day to finish this concrete stuff and need coverage of
fullblown combinations of A-B-C + all-possible-references, yell.
it's in dbcook/tests/test_ABC_inh_ref_all.py
the loss of synchron between the polymorphic_on and the
with_polymorphic[1] if alias'ed, may be a problem one day for
someone, but it's up to you.
ciao
svil
--~--~-~--~~~---~--~~
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: Polymorphic concrete inheritance question
On Dec 3, 2008, at 3:45 PM, [EMAIL PROTECTED] wrote:
>
> okay, then i get this as answer to my other question - so concrete
> polymorhism relations/get()/identity on top of it are blue_sky.
> that's okay - just put a line about it in the docs.
> dbcook is throwing warnings about it since long time.
>
modify your code to use the query.with_polymorphic('*', selectable,
some_discriminator_column) approach in r5413, and then tell me what
issues remain. its not appropriate for with_polymorphic to be set on
a concrete mapper() in most cases.
--~--~-~--~~~---~--~~
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: Polymorphic concrete inheritance question
> > this is still there: > > File "sqlalchemy/orm/mapper.py", line 168, in __init__ > > self.with_polymorphic[1] = self.with_polymorphic[1].alias() > > TypeError: 'tuple' object does not support item assignment > > try mapping to something that is already an alias() (this would > lend insight into your other problem) ah, okay, i'm aliasing my stuff, but removed the alias to check something else and stepped on this one. passing in a list works too. > > also, related question: once there is A-B-C, concrete, how u'd > > get some A by id? query(A).filter_by(id=1) returns 3 objects, one > > of A,B,C. i guess some filter( mapper.polymorphic_on == > > 'Aidentity') should be there, but how to guess if A is inherited > > concrete hence needs that? > > or is that automaticaly done by query.get() and i missed it? > > if B and C inherit from A, then three objects is the right answer > in that case. put this in the bucket of reasons why concrete > table inheritance in conjunction with polymorphic loading by > default should be avoided. > > I was about to advise using query.with_polymorphic() only, no > mapper polymorphic at all, for this case but I realized this is > currently incompatible with the need for a polymorphic > discriminator column. so maybe we can add that as a third argument > to with_polymorphic(). okay, then i get this as answer to my other question - so concrete polymorhism relations/get()/identity on top of it are blue_sky. that's okay - just put a line about it in the docs. dbcook is throwing warnings about it since long time. svil --~--~-~--~~~---~--~~ 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: Polymorphic concrete inheritance question
can i... maybe something like
table_A = Table( 'A', meta,
Column( 'name', String(length=200, ), ),
Column( 'db_id', primary_key= True, type_= Integer, ),
)
table_B = Table( 'B', meta,
Column( 'dataB', String(length=200 ),
Column( 'db_id', primary_key= True, type_= Integer, ),
)
table_C = Table( 'C', meta,
Column( 'name', String(length=200 ),
Column( 'dataC', String(length=200 ),
Column( 'db_id', primary_key= True, type_= Integer, ),
)
meta.create_all()
class A( Base):
props = ['db_id', 'name']
class B( Base):
props = ['db_id', 'dataB']
class C( A):
props = ['db_id', 'name', 'dataC']
pu_a = polymorphic_union( {
'A': table_A,
'C': table_C,
}, 'atype', 'pu_a', ) #concrete table
mapper_A = mapper( A, table_A,
polymorphic_identity= 'A',
polymorphic_on= pu_a.c.atype,
with_polymorphic= ('*', pu_a.alias( 'pu_a' )),
)
mapper_B = mapper( B, table_B,
with_polymorphic= None,
)
mapper_C = mapper( C, table_C,
concrete= True,
inherits= mapper_A,
polymorphic_identity= 'C',
with_polymorphic= None,
)
#populate
a = A()
b = B()
c = C()
a.name = 'anna'
b.dataB = 'gun'
c.name = 'cc'
c.dataC = 'mc'
session = create_session()
session.save(a)
session.save(b)
session.save(c)
session.flush()
def query_by_id( session, klas, idname, oid, ):
#single
if config.session_clear: session.clear()
q = session.query( klas).filter_by( **{idname: oid})
#TODO: filter by atype for concrete?
m = class_mapper( klas)
concrete = bool( m.with_polymorphic[1] )
print
print m.polymorphic_on
print m.with_polymorphic[1].c.atype
if concrete: q= q.filter( m.polymorphic_on ==
klas.__name__)
#if concrete: q= q.filter( m.with_polymorphic[1].c.atype
== klas.__name__)
return q.all()
print query_by_id( session, A, 'db_id', 1, str(a) )
filtering by m.with_polymorphic[1].c.atype is ok (commented).
i guess i see the error:
polymorphic_on is on pu_a,
with_polymorphic is on pu_a.alias()...
but u have some autoaliasing in there anyway, no?
btw, have u planned to get relations to polymorphic concretes to work
somewhen ? eventualy query.get(id) to work? i.e. identity to include
the type
On Wednesday 03 December 2008 22:21:12 Michael Bayer wrote:
> thats strange, i dont suppose you could send me how you're setting
> up that polymorphic union
>
> On Dec 3, 2008, at 3:05 PM, [EMAIL PROTECTED] wrote:
> > and maybe related:
> > def query_by_id( klas, idname, oid, .):
> > q = session.query( klas).filter_by( **{idname: oid})
> > # filter by atype for concrete
> > m = class_mapper( klas)
> > concrete = bool( m.with_polymorphic[1] )
> > if concrete: q= q.filter( m.polymorphic_on == klas.__name__)
> > return q.all()
> >
> > generates a query like
> >
> > SELECT pu_a.*
> > FROM (SELECT A.* FROM "A"
> > UNION ALL
> > SELECT C.* FROM "C")
> > AS pu_a,
> > (SELECT A.* FROM "A"
> > UNION ALL
> > SELECT C.* FROM "C")
> > AS pu_a
> > WHERE pu_a.db_id = ? AND pu_a.atype = ?
> >
> > with repeated union twice in the FROM, and error thereof.
> > Somehow the mapper.polymorphic_on is not recognized as already
> > being there and pulls the union once more?
> > if there's no q.filter( m.polymorphic_on == klas.__name__), no
> > errors (but returns multiple objects).
> >
> > this on latest trunk.
> >
> > svil
> >
> > On Wednesday 03 December 2008 19:29:31 Michael Bayer wrote:
> >> it needed some more work. the final version of this fix is in
> >> r5412.
> >>
> >> On Dec 3, 2008, at 10:49 AM, Gaetan de Menten wrote:
> >>> On Wed, Dec 3, 2008 at 16:04, Michael Bayer
> >>>
> >>> <[EMAIL PROTECTED]> wrote:
> this ones big, i can handle it. the attached patch makes
> your case work, but the problem represented here still makes
> itself apparent in other ways and I havent strength tested
> this patch. you might want to see if this patch works in all
> of your test cases.
> >>>
> >>> FWIW, my (only) "more complete" test involving polymorphic
> >>> concrete inheritance passes too (and produces correct SQL).
> >>> Your patch seem fine and doesn't seem to break unrelated tests.
> >>>
> >>> Thanks for the quick reaction time, as usual.
> >>> --
> >>> Gaëtan de Menten
> >>> http://openhex.org
>
>
--~--~-~--~~---
[sqlalchemy] Re: Polymorphic concrete inheritance question
On Dec 3, 2008, at 2:18 PM, [EMAIL PROTECTED] wrote: > > this is still there: > File "sqlalchemy/orm/mapper.py", line 168, in __init__ > self.with_polymorphic[1] = self.with_polymorphic[1].alias() > TypeError: 'tuple' object does not support item assignment try mapping to something that is already an alias() (this would lend insight into your other problem) > also, related question: once there is A-B-C, concrete, how u'd get > some A by id? query(A).filter_by(id=1) returns 3 objects, one of > A,B,C. i guess some filter( mapper.polymorphic_on == 'Aidentity') > should be there, but how to guess if A is inherited concrete hence > needs that? > or is that automaticaly done by query.get() and i missed it? if B and C inherit from A, then three objects is the right answer in that case. put this in the bucket of reasons why concrete table inheritance in conjunction with polymorphic loading by default should be avoided. I was about to advise using query.with_polymorphic() only, no mapper polymorphic at all, for this case but I realized this is currently incompatible with the need for a polymorphic discriminator column. so maybe we can add that as a third argument to with_polymorphic(). --~--~-~--~~~---~--~~ 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: Polymorphic concrete inheritance question
thats strange, i dont suppose you could send me how you're setting up
that polymorphic union
On Dec 3, 2008, at 3:05 PM, [EMAIL PROTECTED] wrote:
>
> and maybe related:
> def query_by_id( klas, idname, oid, .):
> q = session.query( klas).filter_by( **{idname: oid})
> # filter by atype for concrete
> m = class_mapper( klas)
> concrete = bool( m.with_polymorphic[1] )
> if concrete: q= q.filter( m.polymorphic_on == klas.__name__)
> return q.all()
>
> generates a query like
>
> SELECT pu_a.*
> FROM (SELECT A.* FROM "A"
> UNION ALL
> SELECT C.* FROM "C")
> AS pu_a,
> (SELECT A.* FROM "A"
> UNION ALL
> SELECT C.* FROM "C")
> AS pu_a
> WHERE pu_a.db_id = ? AND pu_a.atype = ?
>
> with repeated union twice in the FROM, and error thereof.
> Somehow the mapper.polymorphic_on is not recognized as already being
> there and pulls the union once more?
> if there's no q.filter( m.polymorphic_on == klas.__name__), no errors
> (but returns multiple objects).
>
> this on latest trunk.
>
> svil
>
> On Wednesday 03 December 2008 19:29:31 Michael Bayer wrote:
>> it needed some more work. the final version of this fix is in
>> r5412.
>>
>> On Dec 3, 2008, at 10:49 AM, Gaetan de Menten wrote:
>>> On Wed, Dec 3, 2008 at 16:04, Michael Bayer
>>>
>>> <[EMAIL PROTECTED]> wrote:
this ones big, i can handle it. the attached patch makes your
case work, but the problem represented here still makes itself
apparent in other ways and I havent strength tested this patch.
you might want to see if this patch works in all of your test
cases.
>>>
>>> FWIW, my (only) "more complete" test involving polymorphic
>>> concrete inheritance passes too (and produces correct SQL).
>>> Your patch seem fine and doesn't seem to break unrelated tests.
>>>
>>> Thanks for the quick reaction time, as usual.
>>> --
>>> 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: Polymorphic concrete inheritance question
and maybe related:
def query_by_id( klas, idname, oid, .):
q = session.query( klas).filter_by( **{idname: oid})
# filter by atype for concrete
m = class_mapper( klas)
concrete = bool( m.with_polymorphic[1] )
if concrete: q= q.filter( m.polymorphic_on == klas.__name__)
return q.all()
generates a query like
SELECT pu_a.*
FROM (SELECT A.* FROM "A"
UNION ALL
SELECT C.* FROM "C")
AS pu_a,
(SELECT A.* FROM "A"
UNION ALL
SELECT C.* FROM "C")
AS pu_a
WHERE pu_a.db_id = ? AND pu_a.atype = ?
with repeated union twice in the FROM, and error thereof.
Somehow the mapper.polymorphic_on is not recognized as already being
there and pulls the union once more?
if there's no q.filter( m.polymorphic_on == klas.__name__), no errors
(but returns multiple objects).
this on latest trunk.
svil
On Wednesday 03 December 2008 19:29:31 Michael Bayer wrote:
> it needed some more work. the final version of this fix is in
> r5412.
>
> On Dec 3, 2008, at 10:49 AM, Gaetan de Menten wrote:
> > On Wed, Dec 3, 2008 at 16:04, Michael Bayer
> >
> > <[EMAIL PROTECTED]> wrote:
> >> this ones big, i can handle it. the attached patch makes your
> >> case work, but the problem represented here still makes itself
> >> apparent in other ways and I havent strength tested this patch.
> >> you might want to see if this patch works in all of your test
> >> cases.
> >
> > FWIW, my (only) "more complete" test involving polymorphic
> > concrete inheritance passes too (and produces correct SQL).
> > Your patch seem fine and doesn't seem to break unrelated tests.
> >
> > Thanks for the quick reaction time, as usual.
> > --
> > 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: Polymorphic concrete inheritance question
this is still there: File "sqlalchemy/orm/mapper.py", line 168, in __init__ self.with_polymorphic[1] = self.with_polymorphic[1].alias() TypeError: 'tuple' object does not support item assignment also, related question: once there is A-B-C, concrete, how u'd get some A by id? query(A).filter_by(id=1) returns 3 objects, one of A,B,C. i guess some filter( mapper.polymorphic_on == 'Aidentity') should be there, but how to guess if A is inherited concrete hence needs that? or is that automaticaly done by query.get() and i missed it? On Wednesday 03 December 2008 19:29:31 Michael Bayer wrote: > it needed some more work. the final version of this fix is in > r5412. > > On Dec 3, 2008, at 10:49 AM, Gaetan de Menten wrote: > > On Wed, Dec 3, 2008 at 16:04, Michael Bayer > > > > <[EMAIL PROTECTED]> wrote: > >> this ones big, i can handle it. the attached patch makes your > >> case work, but the problem represented here still makes itself > >> apparent in other ways and I havent strength tested this patch. > >> you might want to see if this patch works in all of your test > >> cases. > > > > FWIW, my (only) "more complete" test involving polymorphic > > concrete inheritance passes too (and produces correct SQL). > > Your patch seem fine and doesn't seem to break unrelated tests. > > > > Thanks for the quick reaction time, as usual. > > -- > > 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: Polymorphic concrete inheritance question
it needed some more work. the final version of this fix is in r5412. On Dec 3, 2008, at 10:49 AM, Gaetan de Menten wrote: > > On Wed, Dec 3, 2008 at 16:04, Michael Bayer > <[EMAIL PROTECTED]> wrote: > >> this ones big, i can handle it. the attached patch makes your case >> work, but the problem represented here still makes itself apparent in >> other ways and I havent strength tested this patch. you might want >> to see if this patch works in all of your test cases. > > FWIW, my (only) "more complete" test involving polymorphic concrete > inheritance passes too (and produces correct SQL). > Your patch seem fine and doesn't seem to break unrelated tests. > > Thanks for the quick reaction time, as usual. > -- > 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: Polymorphic concrete inheritance question
On Wed, Dec 3, 2008 at 16:04, Michael Bayer <[EMAIL PROTECTED]> wrote: > this ones big, i can handle it. the attached patch makes your case > work, but the problem represented here still makes itself apparent in > other ways and I havent strength tested this patch. you might want > to see if this patch works in all of your test cases. FWIW, my (only) "more complete" test involving polymorphic concrete inheritance passes too (and produces correct SQL). Your patch seem fine and doesn't seem to break unrelated tests. Thanks for the quick reaction time, as usual. -- 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: Polymorphic concrete inheritance question
this ones big, i can handle it. the attached patch makes your case
work, but the problem represented here still makes itself apparent in
other ways and I havent strength tested this patch. you might want
to see if this patch works in all of your test cases.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Index: lib/sqlalchemy/orm/query.py
===
--- lib/sqlalchemy/orm/query.py (revision 5405)
+++ lib/sqlalchemy/orm/query.py (working copy)
@@ -1647,7 +1647,8 @@
self.entities = [entity]
self.entity_zero = entity
-
+self._has_polymorphic_selectable = False
+
def setup_entity(self, entity, mapper, adapter, from_obj,
is_aliased_class, with_polymorphic):
self.mapper = mapper
self.extension = self.mapper.extension
@@ -1668,6 +1669,7 @@
mappers, from_obj = self.mapper._with_polymorphic_args(cls_or_mappers,
selectable)
self._with_polymorphic = mappers
+self._has_polymorphic_selectable = bool(from_obj)
# TODO: do the wrapped thing here too so that with_polymorphic() can be
# applied to aliases
@@ -1748,7 +1750,7 @@
if adapter:
context.order_by =
adapter.adapt_list(util.to_list(context.order_by))
-for value in
self.mapper._iterate_polymorphic_properties(self._with_polymorphic):
+for value in
self.mapper._iterate_polymorphic_properties(self._with_polymorphic,
self._has_polymorphic_selectable):
if query._only_load_props and value.key not in
query._only_load_props:
continue
value.setup(
Index: lib/sqlalchemy/orm/mapper.py
===
--- lib/sqlalchemy/orm/mapper.py(revision 5406)
+++ lib/sqlalchemy/orm/mapper.py(working copy)
@@ -862,18 +862,20 @@
@property
def _default_polymorphic_properties(self):
-return util.unique_list(
+return iter(util.unique_list(
chain(*[list(mapper.iterate_properties) for mapper in [self] +
self._with_polymorphic_mappers])
-)
-
-def _iterate_polymorphic_properties(self, mappers=None):
-if mappers is None:
-return iter(self._default_polymorphic_properties)
+))
+
+def _iterate_polymorphic_properties(self, mappers=None,
has_selectable=False):
+if has_selectable or (self.with_polymorphic and
self.with_polymorphic[1]):
+return self.iterate_properties
+elif mappers is None:
+return self._default_polymorphic_properties
else:
return iter(util.unique_list(
chain(*[list(mapper.iterate_properties) for mapper in [self] +
mappers])
))
-
+
@property
def properties(self):
raise NotImplementedError("Public collection of MapperProperty objects
is "
On Dec 3, 2008, at 9:22 AM, Gaetan de Menten wrote:
>
> On Wed, Dec 3, 2008 at 15:03, Michael Bayer
> <[EMAIL PROTECTED]> wrote:
>
>> um yeah, actually this behavior is affecting all multi-level usage of
>> "polymorphic_union". So, while polymorphic_union is quite obviously
>> (since nobody has noticed this pretty glaring issue) on the decline
>> in
>> the 0.5 series, this is quite severe and ill try to have a look at it
>> today.
>
> Do you want a bug report for this?
>
> --
> 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: Polymorphic concrete inheritance question
On Wed, Dec 3, 2008 at 15:03, Michael Bayer <[EMAIL PROTECTED]> wrote: > um yeah, actually this behavior is affecting all multi-level usage of > "polymorphic_union". So, while polymorphic_union is quite obviously > (since nobody has noticed this pretty glaring issue) on the decline in > the 0.5 series, this is quite severe and ill try to have a look at it > today. Do you want a bug report for this? -- 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: Polymorphic concrete inheritance question
um yeah, actually this behavior is affecting all multi-level usage of
"polymorphic_union". So, while polymorphic_union is quite obviously
(since nobody has noticed this pretty glaring issue) on the decline in
the 0.5 series, this is quite severe and ill try to have a look at it
today.
On Dec 3, 2008, at 4:06 AM, Gaetan de Menten wrote:
> Hello all,
>
> I've been playing a bit with polymorphic concrete inheritance, and
> noticed that when you have several levels of "polymorphic" loading (ie
> my child class is also a parent class which I want to load
> polymorphically), the query for the top-level class includes the child
> polymorphic join while I don't see any reason to (its table is already
> contained in the parent join). See attached example.
>
> class A(object):
>...
>
> class B(A):
>pass
>
> class C(B):
>pass
>
> The query ends up something like:
>
> SELECT [all_columns] FROM ([pjoin_abc]), ([pjoin_bc])
>
> Am I using it wrong, or is this a bug?
>
> --
> Gaëtan de Menten
> http://openhex.org
>
> >
> from sqlalchemy import *
> from sqlalchemy.orm import *
>
> metadata = MetaData()
> metadata.bind = 'sqlite:///'
>
> a_table = Table('a', metadata,
>Column('id', Integer, primary_key=True),
>Column('data1', String(20))
> )
> b_table = Table('b', metadata,
>Column('id', Integer, primary_key=True),
>Column('data1', String(20)),
>Column('data2', String(20))
> )
> c_table = Table('c', metadata,
>Column('id', Integer, primary_key=True),
>Column('data1', String(20)),
>Column('data2', String(20)),
>Column('data3', String(20))
> )
>
> metadata.create_all()
>
> class A(object):
>def __init__(self, **kwargs):
>for k, v in kwargs.iteritems():
>setattr(self, k, v)
>
> class B(A):
>pass
>
> class C(B):
>pass
>
> pjoin_all = polymorphic_union({
>'a': a_table,
>'b': b_table,
>'c': c_table
> }, 'type', 'pjoin')
>
> pjoin_bc = polymorphic_union({
>'b': b_table,
>'c': c_table
> }, 'type', 'pjoin_bc')
>
>
> a_m = mapper(A, a_table,
> with_polymorphic=('*', pjoin_all),
> polymorphic_on=pjoin_all.c.type,
> polymorphic_identity='a')
> b_m = mapper(B, b_table,
> inherits=a_m, concrete=True,
> with_polymorphic=('*', pjoin_bc),
> polymorphic_on=pjoin_bc.c.type,
> polymorphic_identity='b')
> c_m = mapper(C, c_table,
> inherits=b_m, concrete=True,
> polymorphic_identity='c')
>
> Session = sessionmaker()
> session = Session()
>
> a1 = A(data1='a1')
> b1 = B(data1='b1', data2='b1')
> c1 = C(data1='c1', data2='c1', data3='c1')
>
> session.add(a1)
> session.add(b1)
> session.add(c1)
> session.commit()
>
> metadata.bind.echo = True
>
> session.query(A).all()
> print "*" * 20, "B", "*" * 20
> session.query(B).all()
>
--~--~-~--~~~---~--~~
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: Polymorphic concrete inheritance question
hm i had not run my tests for quite a while.. this seems recent thing. lets see if i can dig anything of help... nothing much, one side works, another not at all. one of my set of inheritance tests (direct over sa, A-B) is ok. the other one (over dbcook) fails completely, even for A-B inheritance. But they seem same as mapping... there's something really subtle. i either get a sort of decart product, or empty result. and also i stepped on this: File "sqlalchemy/orm/mapper.py", line 168, in __init__ self.with_polymorphic[1] = self.with_polymorphic[1].alias() TypeError: 'tuple' object does not support item assignment ciao svil On Wednesday 03 December 2008 11:06:24 Gaetan de Menten wrote: > Hello all, > > I've been playing a bit with polymorphic concrete inheritance, and > noticed that when you have several levels of "polymorphic" loading > (ie my child class is also a parent class which I want to load > polymorphically), the query for the top-level class includes the > child polymorphic join while I don't see any reason to (its table > is already contained in the parent join). See attached example. > > class A(object): > ... > > class B(A): > pass > > class C(B): > pass > > The query ends up something like: > > SELECT [all_columns] FROM ([pjoin_abc]), ([pjoin_bc]) > > Am I using it wrong, or is this a bug? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
