I was just considering something similar. Were you able to get far with
this?
On 04/07/2010 03:10 PM, Kyle Schaffrick wrote:
On Wed, 7 Apr 2010 10:15:14 -0400
"Michael Bayer"<mike...@zzzcomputing.com> wrote:
Kyle Schaffrick wrote:
Greetings,
I'm looking into using PostgreSQL's hstore type in a SQLAlchemy
project, and before I possibly reinvent the wheel I was wondering if
anyone has/knows of an implementation of an hstore custom type for
SQLA?
I'm basically just interested in simply mapping a stand-alone
attribute containing a python dict onto an hstore column, I don't
require auto-magic storage of extra attributes directly added to
the object a la examples/vertical.
Mainly I want the hstore segregated into it's own attribute because
I'd like to be able to expose expression language support for
hstore's operators (?, ->, ||, and so forth) to manipulate them
server-side.
Any pointers?
start with 0.6, as we've expanded the capability for types to directly
affect how various operators are rendered, as well as to drive the
return type of expressions, which in turn allows that expression to
have a say in its own usage in another expression, as well as affects
result row behavior.
I had planned on using 0.6 just to get the benefit of the new
dialect+dbapi system.
I did see the @compiles() idiom in some example code, is this what
you're referring to? It looks like a great new feature.
Have there been any thoughts on user-extensible reflection? Some way
to say "when you reflect a DB column of type foo, use this custom type
class"? If I got the right impression from skimming, dispatching
reflected types is essentially a big cascade of if-statements at the
moment. I don't really know how many DBMS's in SA's arsenal have
extensible type systems, so not sure if it's worth the trouble. I
assume you can just override column information piecemeal without
having to give up reflection of columns with vanilla types.
if hstore represents a python value that is "mutable" (which a dict
would be), mixing in MutableType will cause the ORM to maintain a
copy of the original version of the attribute in order to check for
changes.
Good information, thanks. I can see why this would need to be handled
specially.
-Kyle
--
David Gardner
Pipeline Tools Programmer
Jim Henson Creature Shop
dgard...@creatureshop.com
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@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.
