On May 5, 2010, at 11:46 PM, Kyle Schaffrick wrote:
> 1. While you can override existing operators that work on ColumnElements
> without doing much funny business, if you want to add *new* operations
> to it, the abstractions leak fairly badly. This seems to be because
> operator definitions aren't delegated to the class representing the
> type, which is suboptimal because I would think that the type of a
> ColumnElement is what logically "defines" what operations are valid on
> it. The result of this is that I have to create classes like
> HStoreColumn, HStoreColumnElement, _HStoreDeleteFunction, and so on, so
> that SQL expressions which are logically of type 'hstore' will have the
> extended hstore operations available.
yeah I can see how it could go that the entire "comparator" interface moves
onto TypeEngine. There are obviously dozens of major design decisions which
would have to occur for that to happen and there may also be tradeoffs.
>
> 2. That expression operations on Foo.some_col and foo_table.c.some_col
> take completely different paths in the implementation was slightly
> surprising. I would have expected the former to be implemented in terms
> of the latter, so that SQL expressions available on some column type are
> automatically available on the descriptor of a class which maps to that
> column. But I don't know, there might be good reasons for this. In any
> case I'm trying to figure out how to write my Comparator for hstore
> without repeating myself a lot.
Well consider that Foo.some_col does a lot more than a Column object does.
Ultimately its a descriptor object from the attributes package, and this object
is also used for non-column attributes as well. I.e. it would be less
consistent for a mapped object to look like:
class Foo(object):
id = < column object>
related_stuff = <instrumented attribute>
id_synonym = <instrumented attribute>
we try to make the Column and the InstrumentedAttribute systems similar by both
subclassing expression.ColumnOperators, which is where the column-oriented
comparisons occur. Ultimately when you say Foo.some_col == 'foo', it is
getting down to the __eq__() method on foo_table.c.some_col, so ORM comparators
are certainly implemented in terms of the SQL constructs, just maybe theres
more indirection than you would initially think necessary. In GOF speak the
InstrumentedAttribute is a "decorator" (not in the Python sense) - an object
that proxies requests to another, while adding other functionality.
--
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.
