RE: [sqlalchemy] Re: Context based execution
-Original Message- From: sqlalchemy@googlegroups.com [mailto:sqlalchemy@googlegroups.com] On Behalf Of bool Sent: 15 April 2011 14:41 To: sqlalchemy Subject: [sqlalchemy] Re: Context based execution Hi, Thanks a lot. Can someone answer this question also = @compiles(Select) def contextual_select_thing(select, compiler, **kw): This method gets registered with Select. But How/When does this registration automatically happen? The implementation of the compiler extension is very short - you can see it at http://www.sqlalchemy.org/trac/browser/lib/sqlalchemy/ext/compiler.py. It looks like it modifies the target class to add _compiler_dispatcher and _compiler_dispatch attributes to it (or update them if it already has them). The SA statement compiler must look at these attributes to determine how to compile the statement. The registration happens as soon as the @compiles(Select) decorator is evaluated. If it is at module-global scope (rather than being buried inside another function), it'll happen when the module is imported. Hope that helps, Simon -- 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: Context based execution
On Apr 14, 2011, at 9:36 AM, bool wrote: Thanks Michael Trier. Michael Bayer, Can you help me with the other two questions I asked ? yes but I would note that lots of people on this list are capable of answering these questions. Am trying to slow my responses so that others can more easily participate. Why does mapper cache for update/insert/delete This is to improve performance.update/delete statements emitted during the flush are strictly against primary key identity and possibly a version id column and there's no use case for modifying the WHERE criterion ad hoc within a flush. An update that uses a WHERE against fluid criterion is more appropriate in the query.update() use case, where the previous recipe I gave would still work. and can you confirm it does not do this for select and I can safely use this approach for select with ORM? selects aren't cached. The only caching with query comes into play when you use get() - it will fetch the given identity from the identity map if present. Is there a recipe/code which I can quickly refer to get started on before_insert and also how to modify a insert statement in before_insert? there's a short example of before_insert right here: http://www.sqlalchemy.org/docs/orm/interfaces.html#mapper-events -- 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: Context based execution
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. Is there a recipe/code which I can quickly refer to get started on before_insert and also how to modify a insert statement in before_insert? This is the area of the docs that describe before_insert and other MapperExtensions. It's laid out pretty clearly and quite easy to implement: http://www.sqlalchemy.org/docs/orm/interfaces.html#mapper-events -- Michael Trier http://michaeltrier.com/ -- 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: Context based execution
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.
