Re: [sqlalchemy] Is it possible to add another criterion to this backref?

2015-03-25 Thread Adrian
Is what I'm trying to be possible assuming I cannot add any code to the 
User model?
In the future there might be plugins in my application which could contain 
favorites, but while plugins can add their own models, they are never 
allowed to directly modify a class in the application core.

-- 
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.


Re: [sqlalchemy] Is it possible to add another criterion to this backref?

2015-03-25 Thread Adrian
In case it's unclear what exactly I'm trying to do, here's the version with 
the relationship defined right in the User model that works fine.
I'd like to do this exact same thing, but somehow define the relationship 
outside the User model. Preferably by using the normal declarative syntax 
to define the association table and defining the relationship there.

# in the User model:

favorite_users = db.relationship(
'User',
secondary=favorite_user_table,
primaryjoin=id == favorite_user_table.c.user_id,
secondaryjoin=(id == favorite_user_table.c.target_id)  ~is_deleted,
lazy=True,
backref=db.backref('favorite_of', lazy=True),
)

# the association table:
favorite_user_table = db.Table(
'favorite_users',
db.metadata,
db.Column(
'user_id',
db.Integer,
db.ForeignKey('users.users.id'),
primary_key=True,
nullable=False,
index=True
),
db.Column(
'target_id',
db.Integer,
db.ForeignKey('users.users.id'),
primary_key=True,
nullable=False
),
schema='users'
)

-- 
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.


Re: [sqlalchemy] Is it possible to add another criterion to this backref?

2015-03-25 Thread Michael Bayer
Im trying to avoid having to write a full example for you from scratch so if
you could provide everything in one example, both models and where you want
the relationships, with all the columns, we can work from there, thanks.


Adrian adr...@planetcoding.net wrote:

 In case it's unclear what exactly I'm trying to do, here's the version with 
 the relationship defined right in the User model that works fine.
 I'd like to do this exact same thing, but somehow define the relationship 
 outside the User model. Preferably by using the normal declarative syntax to 
 define the association table and defining the relationship there.
 
 # in the User model:
 
 favorite_users = db.relationship(
 'User',
 secondary=favorite_user_table,
 primaryjoin=id == favorite_user_table.c.user_id,
 secondaryjoin=(id == favorite_user_table.c.target_id)  ~is_deleted,
 lazy=True,
 backref=db.backref('favorite_of', lazy=True),
 )
 
 # the association table:
 favorite_user_table = db.Table(
 'favorite_users',
 db.metadata,
 db.Column(
 'user_id',
 db.Integer,
 db.ForeignKey('users.users.id'),
 primary_key=True,
 nullable=False,
 index=True
 ),
 db.Column(
 'target_id',
 db.Integer,
 db.ForeignKey('users.users.id'),
 primary_key=True,
 nullable=False
 ),
 schema='users'
 )
 
 -- 
 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.

-- 
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.


Re[2]: [sqlalchemy] Is it possible to add another criterion to this backref?

2015-03-25 Thread Adrian
Sure, no problem with that.
I'll add a small self-contained example for it tomorrow.

- Adrian

On 25.03.2015 14:21 Michael Bayer wrote:
 Im trying to avoid having to write a full example for you from scratch so if
 you could provide everything in one example, both models and where you want
 the relationships, with all the columns, we can work from there, thanks.

-- 
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.


Re: [sqlalchemy] Re: Dynamically constructing joins

2015-03-25 Thread Greg Silverman
Ha! Ha! On my previous attempts, I had something similar to this, but
instead, I had

query = db.session.query(label('sid',
 distinct(a[1].c.patient_sid)))

if (n  1):
for table in join_tables[1:]:
for criterion in join_criteria[1:]:
query = query.join(eval(table), eval(criterion))

Where the variables table and criterion were built lists, so that I ended
up doing a Cartesian product of all my tables, which was giving me many
problems, with aliasing being the least of it!

Thanks!

Greg--

On Tue, Mar 24, 2015 at 11:22 PM, Jonathan Vanasco jonat...@findmeon.com
wrote:

 any reason why you're not building a query like this?

query = db.session.query(label('sid',
  distinct(a[1].c.patient_sid)))
if n = 2
   query = query.\
 join(a[2],a[2].c.patient_sid==a[1].c.patient_sid)
if n = 3
   query = query.\
 join(a[3],a[3].c.patient_sid==a[1].c.patient_sid)

 or

query = db.session.query(label('sid',
  distinct(a[1].c.patient_sid)))
for i in range(2, n):
   query = query.\
 join(a[i],a[i].c.patient_sid==a[1].c.patient_sid)


  --
 You received this message because you are subscribed to a topic in the
 Google Groups sqlalchemy group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/sqlalchemy/SySyi4CCCUY/unsubscribe.
 To unsubscribe from this group and all its topics, 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.




-- 
Greg M. Silverman
Senior Developer Analyst
Cardiovascular Informatics http://www.med.umn.edu/cardiology/
University of Minnesota
612-626-0919
g...@umn.edu

 ›  flora-script http://flora-script.grenzi.org/ ‹
 ›  grenzi.org  ‹
 ›  evaluate-it.org  ‹

-- 
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.


[sqlalchemy] Re: Dynamically constructing joins

2015-03-25 Thread Jonathan Vanasco
Yeah, there's no reason to touch eval -- and a lot of reasons not to. 
 Security issues aside, when you make a mistake the error will be 
completely unintelligible.

You can create joins dynamically very easily by just iteratively building 
up on it, and using getattr() if needed.

If you're doing any advanced things (subqueries, aliases, etc), I would 
suggest keeping the online docs loaded in a browser window and paying close 
attention to the return values.  Most operations will return a query, but a 
few will return another object.

-- 
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.


[sqlalchemy] Re: Dynamically constructing joins

2015-03-25 Thread Horcle
eval() was definitely not doing what I expected. Thanks for the tip about 
getattr(), and thanks for helping get my head screwed on right!

Greg--

On Wednesday, March 25, 2015 at 11:33:44 AM UTC-5, Jonathan Vanasco wrote:

 Yeah, there's no reason to touch eval -- and a lot of reasons not to. 
  Security issues aside, when you make a mistake the error will be 
 completely unintelligible.

 You can create joins dynamically very easily by just iteratively building 
 up on it, and using getattr() if needed.

 If you're doing any advanced things (subqueries, aliases, etc), I would 
 suggest keeping the online docs loaded in a browser window and paying close 
 attention to the return values.  Most operations will return a query, but a 
 few will return another object.


-- 
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.


Re: [sqlalchemy] polymorphic inheritance and unique constraints

2015-03-25 Thread Richard Gerd Kuesters | Pollux

hell yeah! that's exactly what i was looking for :)

is it in the 1.0.0b3 or upstream?

best regards,
richard.

On 03/24/2015 08:49 PM, Michael Bayer wrote:

are these two separate constraints?  I just looked and it seems like they are 
distinct.

I just added a fix to 1.0 because someone was hacking around something similar 
to this.

The easiest way to get these for the moment is just to create the 
UniqueConstraint outside of the class definition.

class Foo(Base):
 # …

class Bar(Foo):
# …

UniqueConstraint(Bar.x, Foo.y)

that way all the columns are set up, should just work.



Richard Gerd Kuesters | Pollux rich...@pollux.com.br wrote:


well, understanding better the docs for column conflicts, can i use a 
declared_attr in a unique constraint? if yes, my problem is solved :)


On 03/24/2015 10:33 AM, Michael Bayer wrote:

Richard Gerd Kuesters | Pollux
rich...@pollux.com.br
  wrote:



hi all!

i'm dealing with a little problem here. i have a parent table and its two 
inheritances. there is a value that both children have and must be unique along 
either types. is there a way to move this column to the parent and use a 
constraint in the child? my implementation is postgres 9.4+ with psycopg2 only.

if this is single table inheritance then the constraint would most ideally
be placed on the parent class.

if you’re trying to make this “magic” such that you can semantically keep
the unique constraints on the child classes, you’d need to build out a
conditional approach within @declared_attr. IMO I think this is an idealized
edge case that in the real world doesn’t matter much - just do what works
(put the col / constraint on the base).

the approach is described at

http://docs.sqlalchemy.org/en/rel_0_9/orm/extensions/declarative/inheritance.html#resolving-column-conflicts
.
You’d need to make this work for both the column and the constraint.




as a simple example (i'm just creating this example to simplify things), this 
works:

class MyParent(Base):

 foo_id = Column(Integer, Sequence('foo_id_seq'), primary_key=True)
 foo_name = Column(Unicode(64), nullable=False)
 foo_type = Column(Integer, nullable=False)

 __mapper_args__ = {
 polymorphic_on: foo_type,
 polymorphic_identity: 0
 }


class MyChild1(MyParent):

 foo_id = Column(Integer, ForeignKey(MyParent.foo_id), primary_key=True)
 bar_id = Column(Integer, ForeignKey(AnotherEntity.bar_id), nullable=False)
 child1_specific_name = Column(Unicode(5), nullable=False)
 child1_baz_stuff = Column(Boolean, default=False)

 __mapper_args__ = {
 polymorphic_identity: 1
 }

 __table_args__ = (
 UniqueConstraint(bar_id, child1_specific_name,),  # works, bar_id is 
in MyChild1
 )


class MyChild2(MyParent):

 foo_id = Column(Integer, ForeignKey(MyParent.foo_id), primary_key=True)
 bar_id = Column(Integer, ForeignKey(AnotherEntity.bar_id), nullable=False)
 child2_specific_code = Column(UUID, nullable=False)
 child2_baz_stuff = Column(Float, nullable=False)
 
 __mapper_args__ = {

 polymorphic_identity: 2
 }

 __table_args__ = (
 UniqueConstraint(bar_id, child2_specific_code,),  # works, bar_id is 
in MyChild2
 )


but i would like to do this, if possible:

class MyParent(Base):

 foo_id = Column(Integer, Sequence('foo_id_seq'), primary_key=True)
 foo_name = Column(Unicode(64), nullable=False)
 foo_type = Column(Integer, nullable=False)
 bar_id = Column(Integer, ForeignKey(AnotherEntity.bar_id), nullable=False) 
 # since both child uses bar_id, why not having it on the parent?

 __mapper_args__ = {
 polymorphic_on: foo_type,
 polymorphic_identity: 0
 }


class MyChild1(MyParent):

 foo_id = Column(Integer, ForeignKey(MyParent.foo_id), primary_key=True)
 child1_specific_name = Column(Unicode(5), nullable=False)
 child1_baz_stuff = Column(Boolean, default=False)

 __mapper_args__ = {
 polymorphic_identity: 1
 }

 __table_args__ = (
 UniqueConstraint(MyParent.bar_id, child1_specific_name,),  # will it 
work?
 )


class MyChild2(MyParent):

 foo_id = Column(Integer, ForeignKey(MyParent.foo_id), primary_key=True)
 child2_specific_code = Column(UUID, nullable=False)
 child2_baz_stuff = Column(Float, nullable=False)
 
 __mapper_args__ = {

 polymorphic_identity: 2
 }

 __table_args__ = (
 UniqueConstraint(MyParent.bar_id, child2_specific_code,),  # will it 
work?
 )


well, will it work without being a concrete inheritance? :)


best regards,
richard.


--
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