Denis S. Otkidach wrote: > > such ability in SQLAlchemy. There is a suggestion ( > http://groups.google.com/group/sqlalchemy/browse_thread/thread/bcd10e4a2f5c603d/7dc1515973e5c7ba > ) to provide custom query_cls. This probably worked a year ago, but > doesn't work now.
that should absolutely work now. "doesn't work" is never a very useful explanation of a problem. > > Here is query class I pass as query_cls argument to sessionmaker: > > def QueryPublic(entities, session=None): > query = Query(entities, session) > # XXX I haven't ever seen examples with several entities, so I can > test > # this case. > assert len(entities)==1, entities > # XXX Sometimes it's not a model class or mapper, so the following > fails. > cls = _class_to_mapper(entities[0]).class_ > public_condition = getattr(cls, 'public_condition', None) > if public_condition is not None: > query = query.filter(public_condition) > return query > > This works for simple queries, but any access to relation gives an > about Query.get() used for query with condition (this wasn't a case > for 0.4.x). get() should never be called when there's any filtering applied. its a nonsensical operation so 0.5 likes to tell you about it. OK, i've redefined get() method to be less restrictive in > cost of performance: > > class HackedQuery(Query): > > def get(self, ident): > # XXX This works for case when primary key is constructed of > id field > # only. > if isinstance(ident, (tuple, list)): > assert len(ident)==1 > ident = ident[0] > return self.filter_by(id=ident).first() > > This helped for some properties access, but not all. Right now I have > a similar error for statement_from() method. Probably I can fix this > too, but how many methods I have to overwrite to make it working > ever? its not clear here if you want filtering to be applied when lazyloaders fire off or not. Also, get() is really a special method- you've completely broken it above, such that it won't first check the session for the desired object (a major performance element), it wont check the expired status, etc. I'm a little mystified what such a criterion could be that would work across all your tables. I don't understand what's wrong with using relation() to define the appropriate primaryjoin is. If you don't want to "type" it over and over again, just make your own relation() function that applies the desired primaryjoin in an automated fashion and then returns the result of SQLAlchemy's relation(). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
