[sqlalchemy] Re: sqlalchemy + beaker cache
Thanks for the explanation.
I think a ".property" accessor on AssociationProxy is the right
solution.
Right now I am doing something of this sort:
User.groups._get_property().comparator but not sure if that's what
should be done or not.
On Jul 29, 7:20 am, Michael Bayer wrote:
> An association proxy is a Python descriptor attached to a class and by itself
> is not anything like the InstrumentedAttribute/relationship() object used for
> a relationship. So it cannot be passed to mapper options that expect
> InstrumentedAttribute, or those options need to be enhanced to detect when an
> association proxy is passed in, which would be to check for its class as an
> AssociationProxy object, then call _get_property() on it to get the ultimate
> relationship().
>
> It would be a good idea for us to stick a ".property" accessor on
> AssociationProxy so this kind of thing would work automatically but I'd want
> to have tests that it works under all kinds of join()/options() scenarios.
> added #2236 for that.
>
> On Jul 29, 2011, at 12:32 AM, espresso maker wrote:
>
>
>
>
>
>
>
> > Anyone know of another sqlalchemy + beaker example I can look it?
>
> > On Jul 27, 2:05 pm, espresso maker wrote:
> >> Hi there,
>
> >> I am trying to follow the setup in this
> >> examplehttp://www.sqlalchemy.org/trac/browser/examples/beaker_cachingto
> >> enable beaker caching in sqlalchemy. However, I ran into an issue.
>
> >> #1. When I try to cache a relation that happens to be an association
> >> proxy I get the following error:
>
> >> AttributeError: 'AssociationProxy' object has no attribute 'property'
>
> >> This is how my query looks like:
>
> >> def get_user(user_id):
> >> return Session.query(User).\
> >> options(FromCache('default', 'user')).\
> >> options(RelationshipCache('default', 'user_groups',
> >> User.groups)).\
> >> get(user_id)
>
> >> Anyone ran into this problem?
>
> > --
> > 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
> > sqlalchemy+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/sqlalchemy?hl=en.
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] orm mapper polymorphic_identity as collection
Thanks Michael, I was until now using a plain row[u'layers_id_type'] found inspecting row.keys() with debugger (quick and ditry way, I know...) now I changed with your more orthodox row[mytable.c.id_type] (ahem...) I should not have to deal with subqueries so it can stay this way for the time being. I'm reading now for the first time in docs what's TypeDecorator for, and I understand (approximately, please allow me some time to dive into it) your suggestion. My doubt, at the moment is: using Type Decorator will I be able to keep using `mytable.c.id_type` as foreign key to types table (holding type name adn so on) or not? Probably reading docs better I'd get the answer by myself so don't mind... I'll post results if I reach some good point. Thanks again neurino On Fri, Jul 29, 2011 at 4:12 PM, Michael Bayer wrote: > > On Jul 28, 2011, at 7:05 PM, neurino wrote: > > > I tried create_instance event and it fires, now having: > > > > def see_what_type(mapper, context, row, class_): > > if **is_air**: > > return Air() > > else: > > return EXT_CONTINUE > > > > def initialize_sql(engine): > > ... > > layer_mapper = mapper(Layer, layers) > > mapper(Air, inherits=layer_mapper) > > ... > > event.listen(Layer, 'create_instance', see_what_type, > > retval=True) > > > > and setting **is_air** as True I get Air instances querying for Layer > with filled attributes and relationships. > > > > I don't know about other caveats... > > > > Now I have to find a robust way to check id_type (one of `row` items) in > see_what_type. > > yeah thats one of the issues, those old extension interfaces were made > before we had the "aliased" row in place which happens with the more > elaborate subquery/join scenarios. > > For the simple case you'd run in the Column object into the row: > > row[mytable.c.type] > > if you start dealing with subqueries and such, might have to make it look > for a column that "proxies" the "type" column, which is entirely a > workaround for the bad interface: > > for key in row: > if key.shares_lineage(mytable.c.type): >value = row[key] >break > > but even that isn't going to work if you had two different Layer objects in > the same result row. > > Another workaround might be to establish the "type" of the "mytable.c.type" > column using a TypeDecorator - where process_result_value() performs the > rules you're looking for, returning "is_air" or not. Then you'd use > regular polymorphic_on. Maybe give that a try ? > > > -- > 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 > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > > -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] keyword-only arguments in entity constructor confuse mapper
On Jul 29, 2011, at 3:45 AM, Phazorx wrote: > Most of my entities accept various combinations of parameters and it > makes sense for my to use keyword-only pattern of constructors: > > class Person(Root_Entity): >def __init__(self, session, *, first_name, last_name): > > class Address(Root_Entity): >def __init__(self, session, *, street, building, unit=None, > zip=None, office=None, city="My City", region=None, country="My > Country"): > > however, in this case i get following from python while SQLA figures > out relationships: >ValueError: Function has keyword-only arguments or annotations, > use getfullargspec() API which can support them > > full traceback: http://dpaste.com/hold/581307/ > > Everything is peachy as soon as i get rid of "*," in constructor > obviously... but what can i do to preserve such constructors and still > be able to use SQLA? So you're using some Python syntax I've never seen before, let's check (checking...OK its new in Python 3, does not appear to be in the language tutorial either, just in the PEP) and in the first case we'd have to use getfullargspec() in that case when Py3 is in use, however we'd also have to interpret the extended tuple returned by getfullargspec() correctly when we establish instrumentation. If the following patch works, then we could commit once a test is written, though looking at it I'm not optimistic that some significant extra work might be needed to do this correctly. Until then this is an unsupported use case. Ticket #2237 is added http://www.sqlalchemy.org/trac/ticket/2237 . diff -r 87a1dc569235 lib/sqlalchemy/util/compat.py --- a/lib/sqlalchemy/util/compat.py Thu Jul 28 11:53:18 2011 -0400 +++ b/lib/sqlalchemy/util/compat.py Fri Jul 29 10:35:23 2011 -0400 @@ -90,6 +90,11 @@ from urlparse import parse_qsl if py3k: +from inspect import getfullargspec as inspect_getfullargspec +else: +from inspect import getargspec as inspect_getfullargspec + +if py3k: # they're bringing it back in 3.2. brilliant ! def callable(fn): return hasattr(fn, '__call__') diff -r 87a1dc569235 lib/sqlalchemy/util/langhelpers.py --- a/lib/sqlalchemy/util/langhelpers.pyThu Jul 28 11:53:18 2011 -0400 +++ b/lib/sqlalchemy/util/langhelpers.pyFri Jul 29 10:35:23 2011 -0400 @@ -15,7 +15,7 @@ import sys import types import warnings -from compat import update_wrapper, set_types, threading +from compat import update_wrapper, set_types, threading, inspect_getfullargspec from sqlalchemy import exc def _unique_symbols(used, *bases): @@ -149,7 +149,7 @@ 'apply_pos': '(self, a, b, c, **d)'} """ -spec = callable(fn) and inspect.getargspec(fn) or fn +spec = callable(fn) and inspect_getfullargspec(fn) or fn args = inspect.formatargspec(*spec) if spec[0]: self_arg = spec[0][0] > > -- > 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 > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Question about @validates decorator
On Jul 29, 2011, at 8:34 AM, Stefano Fontanelli wrote: > Il 28/07/11 21.17, Michael Bayer ha scritto: >> h well there's not a public API for that. Right now (and with no >> immediate plans to change it) the function should have an attribute called >> "__sa_validators__" which is a list of attribute names.Ultimately there >> are attribute events assigned though the event API doesn't have a documented >> introspection interface (yet) either. >> > > Yes, I read the code of 'validates' decorator function and I found > '__sa_validators__'. > About attribute events... I will read the code next weekend. > My hope? The existence of a public API :) > It is not a problem... Are you interested in a patch? > > Thank you for the great support. I'm interested in lots and lots of patches, with tests that can go straight into our test suite (since I generally don't commit code that isn't covered by at least a simple test, and most of the work in new patches is writing the tests, not the feature) :) , yes. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Re: sqlalchemy + beaker cache
An association proxy is a Python descriptor attached to a class and by itself
is not anything like the InstrumentedAttribute/relationship() object used for a
relationship. So it cannot be passed to mapper options that expect
InstrumentedAttribute, or those options need to be enhanced to detect when an
association proxy is passed in, which would be to check for its class as an
AssociationProxy object, then call _get_property() on it to get the ultimate
relationship().
It would be a good idea for us to stick a ".property" accessor on
AssociationProxy so this kind of thing would work automatically but I'd want to
have tests that it works under all kinds of join()/options() scenarios. added
#2236 for that.
On Jul 29, 2011, at 12:32 AM, espresso maker wrote:
> Anyone know of another sqlalchemy + beaker example I can look it?
>
> On Jul 27, 2:05 pm, espresso maker wrote:
>> Hi there,
>>
>> I am trying to follow the setup in this
>> examplehttp://www.sqlalchemy.org/trac/browser/examples/beaker_cachingto
>> enable beaker caching in sqlalchemy. However, I ran into an issue.
>>
>> #1. When I try to cache a relation that happens to be an association
>> proxy I get the following error:
>>
>> AttributeError: 'AssociationProxy' object has no attribute 'property'
>>
>> This is how my query looks like:
>>
>> def get_user(user_id):
>> return Session.query(User).\
>>options(FromCache('default', 'user')).\
>>options(RelationshipCache('default', 'user_groups',
>> User.groups)).\
>>get(user_id)
>>
>> Anyone ran into this problem?
>
> --
> 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
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] orm mapper polymorphic_identity as collection
On Jul 28, 2011, at 7:05 PM, neurino wrote: > I tried create_instance event and it fires, now having: > > def see_what_type(mapper, context, row, class_): > if **is_air**: > return Air() > else: > return EXT_CONTINUE > > def initialize_sql(engine): > ... > layer_mapper = mapper(Layer, layers) > mapper(Air, inherits=layer_mapper) > ... > event.listen(Layer, 'create_instance', see_what_type, > retval=True) > > and setting **is_air** as True I get Air instances querying for Layer with > filled attributes and relationships. > > I don't know about other caveats... > > Now I have to find a robust way to check id_type (one of `row` items) in > see_what_type. yeah thats one of the issues, those old extension interfaces were made before we had the "aliased" row in place which happens with the more elaborate subquery/join scenarios. For the simple case you'd run in the Column object into the row: row[mytable.c.type] if you start dealing with subqueries and such, might have to make it look for a column that "proxies" the "type" column, which is entirely a workaround for the bad interface: for key in row: if key.shares_lineage(mytable.c.type): value = row[key] break but even that isn't going to work if you had two different Layer objects in the same result row. Another workaround might be to establish the "type" of the "mytable.c.type" column using a TypeDecorator - where process_result_value() performs the rules you're looking for, returning "is_air" or not. Then you'd use regular polymorphic_on. Maybe give that a try ? -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] keyword-only arguments in entity constructor confuse mapper
Most of my entities accept various combinations of parameters and it makes sense for my to use keyword-only pattern of constructors: class Person(Root_Entity): def __init__(self, session, *, first_name, last_name): class Address(Root_Entity): def __init__(self, session, *, street, building, unit=None, zip=None, office=None, city="My City", region=None, country="My Country"): however, in this case i get following from python while SQLA figures out relationships: ValueError: Function has keyword-only arguments or annotations, use getfullargspec() API which can support them full traceback: http://dpaste.com/hold/581307/ Everything is peachy as soon as i get rid of "*," in constructor obviously... but what can i do to preserve such constructors and still be able to use SQLA? -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Question about @validates decorator
Il 28/07/11 21.17, Michael Bayer ha scritto: h well there's not a public API for that. Right now (and with no immediate plans to change it) the function should have an attribute called "__sa_validators__" which is a list of attribute names.Ultimately there are attribute events assigned though the event API doesn't have a documented introspection interface (yet) either. Yes, I read the code of 'validates' decorator function and I found '__sa_validators__'. About attribute events... I will read the code next weekend. My hope? The existence of a public API :) It is not a problem... Are you interested in a patch? Thank you for the great support. Regards, Stefano. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
