[sqlalchemy] Re: Undeferring attributes off joined entities
On further consideration of the interface, what about adding two new keywords to options() - mapper, and id? That way someone with a large group of options to set won't have to type the entity name and/or id on every single option. session.query(Class).options(options for main entity).options(options for other entity, mapper=SomeClass, id=class1) On Dec 11, 8:26 pm, Chris M [EMAIL PROTECTED] wrote: Don't care as long as the functionality is available somehow :) Unless others have objections I say go with whatevers currently implemented. On Dec 11, 7:52 pm, Michael Bayer [EMAIL PROTECTED] wrote: On Dec 11, 2007, at 6:21 PM, Chris M wrote: Okay, does this mean that options() doesn't go off the last entity or is this interface just in addition to that behavior? this currently is in lieu of the options goes off the last entity idea. i tried it that way but this way felt less surprising to me. we can do a poll if you want. --~--~-~--~~~---~--~~ 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: Undeferring attributes off joined entities
On Dec 12, 2007, at 10:07 AM, Chris M wrote: On further consideration of the interface, what about adding two new keywords to options() - mapper, and id? That way someone with a large group of options to set won't have to type the entity name and/or id on every single option. session.query(Class).options(options for main entity).options(options for other entity, mapper=SomeClass, id=class1) thats OK, except it starts getting into more than one way to do it territory. also i wonder if there would someday be some option that doesnt apply to any particular mapper. theres an implementation reason also that very much favors the mapper- embedded-in-the-option approach, which is that the options on the query get re-used on an entirely different query when lazy and deferred loaders load their results. the original query could bundle the options with the mappers sure but at the moment its a little simpler than that (and i really am trying to not complicate things these days) --~--~-~--~~~---~--~~ 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: Undeferring attributes off joined entities
I got the eager loading case to work in 3912. not sure why it didnt
work for you since the approach was similar, but i changed the
interface of eagerload() and similar so you can do eagerload('foo',
SomeOtherClass), where SomeOtherClass you added using add_entity().
thats a little more explicit which i think is less prone to confusion.
havent tested it for deferred attributes yet (and the same mapper
option should be added to defer, undefer).
On Dec 9, 2007, at 3:59 PM, Chris M wrote:
I'll commit what I have and some tests sometime soon so you can see
what's going on (unless you're by chance magical and already know
what's going on!)
--~--~-~--~~~---~--~~
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: Undeferring attributes off joined entities
Okay, does this mean that options() doesn't go off the last entity or
is this interface just in addition to that behavior?
On Dec 11, 2:35 pm, Michael Bayer [EMAIL PROTECTED] wrote:
I got the eager loading case to work in 3912. not sure why it didnt
work for you since the approach was similar, but i changed the
interface of eagerload() and similar so you can do eagerload('foo',
SomeOtherClass), where SomeOtherClass you added using add_entity().
thats a little more explicit which i think is less prone to confusion.
havent tested it for deferred attributes yet (and the same mapper
option should be added to defer, undefer).
On Dec 9, 2007, at 3:59 PM, Chris M wrote:
I'll commit what I have and some tests sometime soon so you can see
what's going on (unless you're by chance magical and already know
what's going on!)
--~--~-~--~~~---~--~~
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: Undeferring attributes off joined entities
On Dec 11, 2007, at 6:21 PM, Chris M wrote: Okay, does this mean that options() doesn't go off the last entity or is this interface just in addition to that behavior? this currently is in lieu of the options goes off the last entity idea. i tried it that way but this way felt less surprising to me. we can do a poll if you want. --~--~-~--~~~---~--~~ 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: Undeferring attributes off joined entities
Is this how you want to do it? Unfortunately, just your fix alone
doesn't do the trick BUT if you change line 901 of query.py to
context.exec_with_path(m, value.key, value.setup, context,
parentclauses=clauses)
it works, and all ORM tests run fine.
On Dec 8, 10:59 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On Dec 8, 2007, at 9:55 PM, Chris M wrote:
One thing I'd be worried about is that after an add_entity there is no
way to set options on the main entity afterwards. You could provide a
reset_entitypoint, but it wouldn't work the same as with joins because
after a reset_joinpoint you can rejoin along the same path to filter
more criterion if necessary. Still, I think some functionality is
better than no functionality... it's not that big of a deal, is it?
when the notion of reset_entitypoint comes in, things have just
gottten out of hand. at some point we're going to have to decide
that order is significant with query's generative behavior, and people
will have to use it with that knowledge in mind. its already been
suggested as a result of other behaviors (such as
query[5:10].order_by('foo') doesnt generate a subquery, for example).
--~--~-~--~~~---~--~~
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: Undeferring attributes off joined entities
On Dec 9, 2007, at 1:21 PM, Chris M wrote: Is this how you want to do it? Unfortunately, just your fix alone doesn't do the trick BUT if you change line 901 of query.py to context.exec_with_path(m, value.key, value.setup, context, parentclauses=clauses) it works, and all ORM tests run fine. I think we should go for it, if for no other reason than add_entity() is a fairly new method, so its better we start establishing the ordered behavior sooner rather than later. Id be curious to know if acutal eager loads work off the second entity also (im thinking...maybe ? ). you can commit this change if you'd like, but id ask that a few (very short) tests be added to test/orm/query.py which validate the behavior of options() both with and without an add_entity() (i.e., a test that would fail if you didnt implement the feature). --~--~-~--~~~---~--~~ 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: Undeferring attributes off joined entities
Nope, eagerloads are a no-go. I tried changing 901 of query.py again to: context.exec_with_path(m, value.key, value.setup, context, parentclauses=clauses, parentmapper=m) but that did not work either. The code around exec_with_path and setup_query confuses me, I'm not sure I can fix eagerloads by myself. Currently without setting parentmapper=m it tries to find the columns in the table of the main entity, so I think this is at least a step in the right direction. On Dec 9, 2:15 pm, Michael Bayer [EMAIL PROTECTED] wrote: On Dec 9, 2007, at 1:21 PM, Chris M wrote: Is this how you want to do it? Unfortunately, just your fix alone doesn't do the trick BUT if you change line 901 of query.py to context.exec_with_path(m, value.key, value.setup, context, parentclauses=clauses) it works, and all ORM tests run fine. I think we should go for it, if for no other reason than add_entity() is a fairly new method, so its better we start establishing the ordered behavior sooner rather than later. Id be curious to know if acutal eager loads work off the second entity also (im thinking...maybe ? ). you can commit this change if you'd like, but id ask that a few (very short) tests be added to test/orm/query.py which validate the behavior of options() both with and without an add_entity() (i.e., a test that would fail if you didnt implement the feature). --~--~-~--~~~---~--~~ 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: Undeferring attributes off joined entities
I'll commit what I have and some tests sometime soon so you can see what's going on (unless you're by chance magical and already know what's going on!) --~--~-~--~~~---~--~~ 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: Undeferring attributes off joined entities
On Dec 9, 2007, at 3:59 PM, Chris M wrote: I'll commit what I have and some tests sometime soon so you can see what's going on (unless you're by chance magical and already know what's going on!) im doing some surgery on Query at the momentmight be better if you wait for the next checkin. --~--~-~--~~~---~--~~ 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: Undeferring attributes off joined entities
On Dec 8, 2007, at 6:17 PM, Chris M wrote: t1, t2 = Table1 .options (undefer (table2.large_col)).join(table2).add_entity(Table2).first() does not load large_col (or even put it in the SQL sent) on t2. Is undefer meant for eager loading in this scenario only, or have I stumbled upon a bug? (if the former, is there a way to achieve what I was trying to do?) query options currently only apply to the main entity.in this case specfically a new syntax would need to be introduced since its not clear if the above option applies to the attribute as applied to the Table1.table2.large_col attribute or on the large_col attribute on the secondary entity (since the two collections of Table2 could be disjoint). --~--~-~--~~~---~--~~ 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: Undeferring attributes off joined entities
options() could work like joinpoints do - after an add_entity, options() refers to that entity. On Dec 8, 7:12 pm, Michael Bayer [EMAIL PROTECTED] wrote: On Dec 8, 2007, at 6:17 PM, Chris M wrote: t1, t2 = Table1 .options (undefer (table2.large_col)).join(table2).add_entity(Table2).first() does not load large_col (or even put it in the SQL sent) on t2. Is undefer meant for eager loading in this scenario only, or have I stumbled upon a bug? (if the former, is there a way to achieve what I was trying to do?) query options currently only apply to the main entity.in this case specfically a new syntax would need to be introduced since its not clear if the above option applies to the attribute as applied to the Table1.table2.large_col attribute or on the large_col attribute on the secondary entity (since the two collections of Table2 could be disjoint). --~--~-~--~~~---~--~~ 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: Undeferring attributes off joined entities
On Dec 8, 2007, at 7:25 PM, Chris M wrote:
options() could work like joinpoints do - after an add_entity,
options() refers to that entity.
probably. ive been hesitant to make things go off of add_entity() as
of yet.though actually this is probably not very hard to do. youd
have to add the option as undefer('large_col'), and i bet if you were
to change line 542 of interfaces.py to:
if query._entities:
mapper = query._entities[-1][0]
else:
mapper = query.mapper
it *might* work with just that change.
--~--~-~--~~~---~--~~
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: Undeferring attributes off joined entities
One thing I'd be worried about is that after an add_entity there is no
way to set options on the main entity afterwards. You could provide a
reset_entitypoint, but it wouldn't work the same as with joins because
after a reset_joinpoint you can rejoin along the same path to filter
more criterion if necessary. Still, I think some functionality is
better than no functionality... it's not that big of a deal, is it?
On Dec 8, 8:23 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On Dec 8, 2007, at 7:25 PM, Chris M wrote:
options() could work like joinpoints do - after an add_entity,
options() refers to that entity.
probably. ive been hesitant to make things go off of add_entity() as
of yet.though actually this is probably not very hard to do. youd
have to add the option as undefer('large_col'), and i bet if you were
to change line 542 of interfaces.py to:
if query._entities:
mapper = query._entities[-1][0]
else:
mapper = query.mapper
it *might* work with just that change.
--~--~-~--~~~---~--~~
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: Undeferring attributes off joined entities
On Dec 8, 2007, at 9:55 PM, Chris M wrote:
One thing I'd be worried about is that after an add_entity there is no
way to set options on the main entity afterwards. You could provide a
reset_entitypoint, but it wouldn't work the same as with joins because
after a reset_joinpoint you can rejoin along the same path to filter
more criterion if necessary. Still, I think some functionality is
better than no functionality... it's not that big of a deal, is it?
when the notion of reset_entitypoint comes in, things have just
gottten out of hand. at some point we're going to have to decide
that order is significant with query's generative behavior, and people
will have to use it with that knowledge in mind. its already been
suggested as a result of other behaviors (such as
query[5:10].order_by('foo') doesnt generate a subquery, for example).
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
