lets first take the "name" parameter out of CalculatedClause since it doesnt even seem to be used, make a subclass of CalculatedClause called "ExpressionClause", make a function "_expression_" to create one, give it an optional keyword-based "name" parameter, and have its visit_expression method i
Hey All,
Sort of related to this is, for sub-selects again, the option of specifying
labels for other compound clauses, such as and_() and or_(). The following
snippet of code works fine:
valid_clause = and_(source.c.ts >= from_ts)
items = select([sql.CalculatedClause('lbl', valid_clause).
Hey Gambit,Yeah, we'll need a way to alias the column created by the subquery. Have you tried using the "use_labels" switch on the inner query?RickOn 5/13/06,
Gambit <[EMAIL PROTECTED]> wrote:
Hey Rick,I was playing with this patch a bit and noticed that while it seems prettygood for select()'s, i
I've been through the internals a bit, and this direction sounds like the way to go, but I understand that there's going to be a bit of refactoring for 0.2. I'd want Mike in on this for an opinion, anyway. Copying him on this message -- what's up with the list for you guys? Seems to be working OK f
OK, this patch against trunk r#1455 works with your testcase.
It defines a new CalculatedClause() class similar to that of Function(), and refactors Function() to derive from this new class.
Also adds new visit_calculatedclause() function to handle the compile-time part.
It requires the use of l
seems to work, committed in the trunk + merge to 0.2, test case is test/case_statement.pyOn May 15, 2006, at 7:22 PM, Rick Morrison wrote:OK, this patch against trunk r#1455 works with your testcase. It defines a new CalculatedClause() class similar to that of Function(), and refactors Function()
Hey Rick,
Basically the issue as I see it is that whatever decides that something is a
'column', and thus part of the result set, doesn't (for the obvious reasons)
know what to do with the CompoundClause. Now this might be rectified as
simply as implementing a new class, say, arbitrarily, 'Calcul
Hey Rick,
I was playing with this patch a bit and noticed that while it seems pretty
good for select()'s, it falls apart in sub-selects. It doesn't propagate as
a column, thus doesn't get an alias for the outer select to work off of, and
it all falls apart :)
Hopefully there's an easy way to sol
Hey Mike:
Attached please find a patch against trunk r#1441 that implements the SQL CASE construct.
I know you've argued in the past for an implementation in some kind of
.ext-land, but let me at least present a few arguments for inclusion in
the core library. I'll do this in the form of response
rick -10 lines of code, yah you got it, this is great. it seemed very complex at the time but this is totally simple. ill get it checked in soon.- mikeOn May 11, 2006, at 5:17 PM, Rick Morrison wrote:Hey Mike: Attached please find a patch against trunk r#1441 that implements the SQL CASE constr
I love the CASE statement, but yah I think its a cleaner in a view (also what DB's support this one ? let me guess, PG and Oracle and thats itoh and MSSQL-9.nobodyhasit :) ). You can use literal strings too for this kind of thing.if you have some brilliant notion of how this would even look
I would think that the "right thing" to do here would be to map a view containing your case, instead of kludging this into the mapper code.On 3/17/06,
Rick Morrision <[EMAIL PROTECTED]> wrote:
Hey Mike -- are there any plans for support for the CASE construct as a column type? Is anyone else inter
Hey Mike -- are there any plans for support for the CASE construct as a column type? Is anyone else interested in this?CASE WHEN [condition] THEN [result] [WHEN ...] [ELSE result]END
Rick
13 matches
Mail list logo
