On Tuesday, March 5, 2013 2:52:59 PM UTC-5, Jason wrote: > > > > On Tuesday, March 5, 2013 11:09:00 AM UTC-5, Michael Bayer wrote: >> >> >> On Mar 5, 2013, at 9:45 AM, Jason <ja...@deadtreepages.com> wrote: >> >> > Hello, >> > >> > I'm looking or some direction on how to implement the SQL syntax when >> querying Postgres' composite types. In case you're unfamiliar: the >> composite types in Postgres are a type that contains attributes which are >> regular SQL types. The attribute to type relationship is similar to the >> column to table relationship (except there are no constraints on >> attributes). A table column can be this composite type. Psycopg2 implements >> this by instantiating a namedtuple on retrieval or accepting a namedtuple >> on update/insert (you can also use your own custom class). The saving and >> retrieval isn't a problem with SQLAlchemy, I just pass through the >> namedtuple to/from Psycopg2. >> > >> > What I need to implement is the SQL syntax for querying composite type >> attributes. Postgres allows this by using the syntax >> "(table_name.column_name).attribute_name = 'bleh'" or just >> "(column_name).attribute_name = 'bleh'" when a table identifier is not >> required. I'm not sure how to go about this because the sql generation >> needs to change the way the column name is output, would this require >> subclassing the ColumnClause? I think I just need to know where to override >> the behaviour of generating the qualified column name in statements. >> >> you'd be doing ColumnElement here which is the more fundamental object. >> It's discussed here in "subclassing guidelines": >> http://docs.sqlalchemy.org/en/rel_0_8/core/compiler.html#subclassing-guidelines >> >> >> if you're on 0.8 the integration here can be very smooth, using custom >> operators ( >> http://docs.sqlalchemy.org/en/rel_0_8/core/types.html#types-operators) >> you could have an approach that looks like: >> mytable.c.column.attrs.attribute_name == "value". The "attrs" namespace >> would call into your custom ColumnElement. >> >> Since the custom operator API is a total blast to use here's a proof of >> concept: >> >> >> >> > Wow thats great, thanks! > > There is a problem with this when using declarative and a reflected base. > My Column's type get's overrwritten with NullType even though I've set > autoreload_replace=False when constructing the table. I am still using the > example ReflectedBase that was in the 0.7 documentation (because the new > DeferredReflection class in 0.8 raises a NoReferencedTableError when > configure_mappers() is called). Any idea how this reflected base is > overwriting the type?: > > I figured out the problem. It's not finding the table in the metadata (because it's schema qualified in metadata.tables) and so it creates it anew.
-- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
