On 8/12/15 3:45 PM, MR M wrote:
Thanks a lot for the response, definitely helpful to know that I
wasn't crazy not able to find some readily available support.
We don't have triggers for performance reasons in some other
applications, but would like to still have quick crud running in
python+sqlalchemy. Are there any events that might be kicked off as
it's creating insert/update/delete objects for an instance state?
yup, look through all the ORM events here:
http://docs.sqlalchemy.org/en/rel_1_0/orm/events.html
In this case you might want to look at before_flush(). An easy way to
go here is to map subclasses directly to the inherits partitions as
illustrated in this recipe:
https://bitbucket.org/zzzeek/sqlalchemy/wiki/UsageRecipes/PostgreSQLInheritance
I think ORM events might be a better choice for this kind of thing
rather than trying to instrument at the Core; however if you wanted to
do Core you'd probably want to use before_execute(). That will give
you a handle to the statement for which you can modify it in place.
What I don't think you'll see is that this performs *better* than a
Postgresql trigger, however. Anything PG does natively is going to be
more performant than manipulating things in Python beforehand.
I was checking out visit_delete for instance, but couldn't figure out
how to access the underlying orm object or even the parameters in that
case (is there any way to get the parameters?). Is the orm
interactions with table mostly disjoint, and we are only passing the
necessary parameters to the core apis?
Thanks again!
On Wednesday, August 12, 2015 at 2:33:02 PM UTC-4, Michael Bayer wrote:
On 8/12/15 1:04 PM, MR M wrote:
> Hi,
>
> Somewhat new to sqlalchemy, and I've read thru a lot of
documentation
> about horizontal sharding and polymorphism features, but I'm still
> unsure of how to support postgresql partitioned tables with ORM.
>
> on the database side, I have (just a dummy example):
>
> -- start
> create table account (
> user_id serial not null,
> name varchar(100),
> primary key(user_id))
> ;
> create table acount_a (
> check(substring(name, 1, 1) = 'A')
> ) inherits (account)
> ;
> create table acount_b (
> check(substring(name, 1, 1) = 'B')
> ) inherits (account)
> ;
> --- end
>
>
> on the ORM side i just have:
>
> class Account(Base):
> __tablename__ = 'account'
> id = Column('user_id', ....)
> name = Column(Varchar(100)...)
>
>
> I'd like to insert a new Account(name='Bob'), and have the
record be
> inserted to account_b in code instead of relying on database
triggers
> or rules.
If you're already relying on PG's special features, you would be best
off using the triggers as their documentation states. While there
might be ways to implement half of PG's documented system on the
Python
side using various events and other features, it would be complicated
and buggy. PG's triggers and stored procedures can certainly handle
the entire job of keeping this sharding transparent so I don't see
why
these have to be reinvented in Python.
--
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
<mailto:sqlalchemy+unsubscr...@googlegroups.com>.
To post to this group, send email to sqlalchemy@googlegroups.com
<mailto:sqlalchemy@googlegroups.com>.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
--
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.
