That's a totally fair answer! Mostly, I wish some sense of relational
change over time was built into SQL, the way it is in BigTable style
systems.
Maybe you could shed a little light on how to use the overlap
operator? I'm having trouble getting the multiple fields into the
clause statement.
In [43]:
session.query(Membership).filter(Membership.start.op('OVERLAPS',[1,100]))
TypeError: op() takes exactly 2 arguments (3 given)
It would also be have / emulate a .when(ts) method in queries (perhaps
via a query subclass) that would take the "timings" into account, but
this does smack of magic as you suggest!
Thanks for the advice!
Gregg
On Thu, Jul 16, 2009 at 10:17 AM, Michael Bayer<[email protected]> wrote:
>
> Gregg Lind wrote:
>>
>> Questions:
>>
>>
>> 1. Is there a "SQLAlchemical" way to write group_snapshot_ts into
>> a declarative class, such that the joins and loader respect the
>> time
>> constraints? (Read-only is fine as well on the loaded attributes)
>> a. eager_loader?
>> b. subclassing query?
>
> im really not in favor of trying to build "magic" awareness of things like
> this into mappers and query subclasses. If you have complex conditions
> to be queried upon I am a fan of abstracting the common kinds of queries
> you need into Python functions and/or class methods. no magic, just
> regular old application architecture.
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
