Was hoping for the patch :). Its not that hard. Easier than the workaround, except for writing the tests, which is only hard because it involves faithfully copying the style of how we do our other tests.
Anyway the subclass query approach means you'd wrap _compile_context, get the return value of it, add your special flag to context.statement, which is the select() construct. This can be messy if the query is wrapping the select() inside of a subquery, not the usual case. The "special flag" here is something you attach to the "Select()" object, which you'd then pick up using the @compiles decorator, and then you'd need to alter the string generation, probably after the fact using a regular expression. Meaning, call compiler.visit_select(select), get the string back that is the final "SELECT" string, alter the string. The example at http://www.sqlalchemy.org/docs/core/compiler.html#changing-the-default-compilation-of-existing-constructs is somewhat similar in that it overrides the compilation of an existing construct. There's not a great way to intercept the middle of the SELECT compilation with a new kind of clause in this case. Its not very ideal, we don't have good hooks in there for customizing for_update right now. On Feb 3, 2011, at 8:41 PM, Kent wrote: > I'm not especially familiar with this code. I understand subclassing > query and adding @_generative method to capture the state, but could > you > point to an example or expound a little for how I get my query class > to > add to the end of the select(). I'm not /*replacing* / > _compile_context > I hope, right? Rather I would invoke super()._compile_context() and > tack > the FOR UPDATE to its result context.statement? I'm unclear on what > type of class I'd subclass for the target of my @compiles() decorator > and, more importantly, how I incorporate that class (would I make > that > class *hold* the context.statement and then when compiling, invoke > compiler.process() on the statement and tack %s FOR UPDATE OF %s to > the end? > > Thanks again. > > > > On Feb 3, 5:06 pm, Michael Bayer <[email protected]> wrote: >> Theres a ticket to support database-specific FOR UPDATE options in trac, for >> now you'd need to use the usual routes into modifying the select statement >> (@compiles for the select() construct, place extra _state on the select() >> object read by your function, regexp it into the string, subclass Query to >> add a new generative method to establish the state on Query and override >> _compile_context to plug it onto context.statement). >> >> Or if you want to provide a full patch with unit tests, that works too and >> I'll commit. >> >> On Feb 3, 2011, at 4:39 PM, Kent wrote: >> >>> session.query(Cls).with_lockmode('update') >> >>> will render "FOR UPDATE" >> >>> Is there a way to render "FOR UPDATE OF <table or column>"? >> >>> I ask because postgresql complains about locking FOR UPDATE when given >>> an outer join. BUT, it is happy if you say "FOR UPDATE OF <left hand >>> table>" given an outer join. >> >>> Thanks in advance, >>> Kent >> >>> -- >>> 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 >>> 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 [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. > -- 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.
