yup, i know (this pattern) it is not ideal; i was just testing the new
features of sa 1.0 regarding postgres (since i'm actually hands-on). i
should rewrite a whole part of my model (and listeners and extensions
and so on), which are already working with polymorphism.
i will change this pattern, but for now i had to know where i can go
with those features to reach any other gain in postgres. i listed my
steps in 1,2,3,4 so it's easier to spot where my mistake was (because i
was sure it was mine).
:)
when i got the time this kind of implementation deserves, then i'll hook
up on rewriting the model. thanks for the support and sorry if this
wasted your time!
cheers,
richard.
On 04/15/2015 04:09 PM, Mike Bayer wrote:
The pattern you're doing is not what Posgresql INHERITS is really
intended for. PG's feature is intended for transparent sharding of
data to different tablespaces, not to simulate OR-mapped class
hierarchies. The keyword is mis-named in this regard. Concrete inh is
in all cases a tough road to travel because it's difficult to relate
things to a whole set of tables which each act as "the table" for a class.
--
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.
For more options, visit https://groups.google.com/d/optout.
