On Apr 1, 2011, at 2:41 AM, bool wrote:
> Thanks Michael. I will try your suggestion.
>
> But I would like the date context to be applied while executing and
> not actually modify the select statement to support the use-case where
> I have a select statement and would the same select to be executed in
> different date contexts.
>
> =======================================
> t1 = table('t1', column('a'), column('b'), column('c'))
>
> s = select([t1])
>
> With DateContext(b = 12)
> conn.execute(s) ----> This would actually execute
> "select a, b, c from t1 where b = 12"
>
> With DateContext(b = 13)
> conn.execute(s) ------> This would actually execute
> "select a, b, c from t1 where b = 13"
> ========================================
right so select.where() is a generative method and you'll note the example
assigns the return result of where() back to itself. The original select() is
unmodified.
>
>
> Also I have these questions
>
> 1. Can we acheive the same thing if user uses sessions to query
>
> With DateContext(b = 12):
> result = session.query(MyObj) ---> b =12 condtion should
> be automatically applied here.
Query uses select() to build its SQL so you get ORM usage for free, although it
would assume that you're emitting .all() or otherwise iterating the Query
within the "with:", as the select() is built only at the point of iteration.
If you wanted your context to be more specific to the actual Query and not the
underlying select constructs you can do the same kind of idea and subclass
Query. Some related recipe is at
http://www.sqlalchemy.org/trac/wiki/UsageRecipes/PreFilteredQuery
>
>
> 2. Can we acheive the same thing with updates/inserts and not just
> with selects
updates and deletes also feature a generative where() method so the same idea
can be applied there. An INSERT has no where criterion so the specific recipe
would not apply. INSERT does feature a values() method that can add
additional values for execution. The caveat however for
update/insert/delete when used with the ORM is that the mapper caches its
compilation of these constructs, so its very likely that the recipe as is used
in conjunction with an ORM flush would cache the modified version of the
constructs and generally break everything. The idiomatic way to modify the
insert/update/delete construct within a flush is to use MapperExtension
before_insert/before_update/before_delete to modify the mapped object's state
right before it's flushed.
--
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.
