Re: [sqlalchemy] Re: all

2012-07-12 Thread Michael Bayer
On Jul 11, 2012, at 8:27 PM, Gunnlaugur Briem wrote: Hi burgiduroy, On Wednesday, 11 July 2012 15:24:59 UTC, burgiduroy wrote: Are there any performance difference between the two? for row in query_object.all(): do_something() AND for row in query_object: do_something()

[sqlalchemy] Custom in-query-only rendering for TypeDecorator types?

2012-07-12 Thread Russ
I currently define a custom column type for ensuring that dates stored to the DB are offset-aware UTC, and convert to to the appropriate timezone on retrieval, using a class something like this: import pytz import sqlalchemy as sa class UTCEnforcedDateTime(sa.types.TypeDecorator): DateTime

Re: [sqlalchemy] Custom in-query-only rendering for TypeDecorator types?

2012-07-12 Thread Michael Bayer
On Jul 12, 2012, at 2:58 PM, Russ wrote: I'm trying to figure out how to change this so that, rather than converting in python, the conversion happens at the database layer using AT TIME ZONE syntax. I've tried using @compiles as follows: #THIS CODE DOES NOT WORK...

Re: [sqlalchemy] Custom in-query-only rendering for TypeDecorator types?

2012-07-12 Thread Russ
On Thursday, July 12, 2012 3:12:26 PM UTC-4, Michael Bayer wrote: There is no functionality right now that allows special SQL to be automatically associated with a type, as associated with an enclosing column expression, at query time. There's a ticket to begin making this kind of thing

Re: [sqlalchemy] Custom in-query-only rendering for TypeDecorator types?

2012-07-12 Thread Michael Bayer
On Jul 12, 2012, at 5:15 PM, Russ wrote: I've got it mostly working using this method, but have hit a few roadblocks. It was pretty easy to intercept Column definitions that were given the UTCEnforcedDateTime type and, with this done, then use DTColumn wrapper type instead with an

Re: [sqlalchemy] Custom in-query-only rendering for TypeDecorator types?

2012-07-12 Thread Russ
However... element.table.name doesn't seem like it can be used directly. It occasionally comes up with strings like %(79508240 log_event)s, which clearly is getting substituted in the guts somewhere when I don't do this. To clarify, I've just determined that this is specifically

Re: [sqlalchemy] Custom in-query-only rendering for TypeDecorator types?

2012-07-12 Thread Russ
On Thursday, July 12, 2012 5:42:12 PM UTC-4, Michael Bayer wrote: let the compiler do it: elementName = compiler.process(element, **kw) That causes an infinite loop since it tries to compile DTColumn itself. I've tried stuff like super(DTColumn, element).compile(), but that doesn't help

Re: [sqlalchemy] Custom in-query-only rendering for TypeDecorator types?

2012-07-12 Thread Michael Bayer
oh right. yeah call compiler.visit_column(element, **kw). On Jul 12, 2012, at 5:59 PM, Russ wrote: On Thursday, July 12, 2012 5:42:12 PM UTC-4, Michael Bayer wrote: let the compiler do it: elementName = compiler.process(element, **kw) That causes an infinite loop since it tries to

Re: [sqlalchemy] Custom in-query-only rendering for TypeDecorator types?

2012-07-12 Thread Russ
oh right. yeah call compiler.visit_column(element, **kw). Perfect... that did the trick, thanks!!! Since the end result isn't much more than this example: http://docs.sqlalchemy.org/en/rel_0_7/core/compiler.html#synopsis it may be worth updating it to replace 'element.name' with

Re: [sqlalchemy] Re: all

2012-07-12 Thread burgiduroy
So which is the best practice? for row in query or for row in query.all() On Thu, Jul 12, 2012 at 8:54 PM, Michael Bayer mike...@zzzcomputing.comwrote: On Jul 11, 2012, at 8:27 PM, Gunnlaugur Briem wrote: Hi burgiduroy, On Wednesday, 11 July 2012 15:24:59 UTC, burgiduroy wrote: Are