[sqlalchemy] Re: backrefs
I assume the non public property._reverse_property is just what I'm looking for. :) On Jan 26, 2:06 pm, Kent jkentbo...@gmail.com wrote: Is there a straightforward way to determine if a RelationshipProperty has a corresponding reverse (backref)? -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@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.
[sqlalchemy] Re: Backrefs and the identity map
I wrote: Hi, Does accessing a backref always have to issue SQL, even if the object to be loaded already exists in the identity map? For example, if I have a many-to-one lazy-loaded relationship from Master to Detail with a backref, the statement master.details[0].master will issue SQL for the '.master' backref, even though it already exists in the session. I know [SNIP] So query.get doesn't issue a query, but master.details[0].master does. Is there any way of making the backref use query.get, and thereby use the identity map? I delved into the source to find out how this works, and I see that the LazyLoader strategy has an attribute 'use_get' which is meant to do exactly this. However the test to see whether the lazywhere clause is the same as the mapper's get() clause is failing: In [1]: import satest2 In [2]: s = satest2.Detail.master.property.strategy In [3]: s.mapper._get_clause[0].compare(s._LazyLoader__lazywhere) Out[3]: False In [4]: print s.mapper._get_clause[0] master.id = ? In [5]: print s._LazyLoader__lazywhere master.id = ? In [6]: print s.mapper._get_clause[0].left master.id In [7]: print s._LazyLoader__lazywhere.left master.id In [8]: print s.mapper._get_clause[0].left.compare(s._LazyLoader__lazywhere.left) False So even though both clauses are binary expressions representing master.id = ?, the master.id in each case is different. On the offchance, I changed the foreign key definition from: master_id = sa.Column(sa.Integer, sa.ForeignKey(Master.id)) to master_id = sa.Column(sa.Integer, sa.ForeignKey(Master.__table__.c.id)) ...and now it seems to work! So is this a bug? Thanks, Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Backrefs and the identity map
King Simon-NFHD78 wrote: to master_id = sa.Column(sa.Integer, sa.ForeignKey(Master.__table__.c.id)) ...and now it seems to work! So is this a bug? yes, that would be a bug. There are some other scenarios where this kind of thing occurs (lazy clause doesn't optimize) related to inheritance but they are less clear cut as bugs. Another point though, if you upgrade to trunk /0.5.6, many-to-one backrefs wont even fire off anymore if unloaded, when they are accessed in the backref context. anyway my hunch is that the Column you get back from Master.id is a proxy to the real one, so we'd have to figure some way for ForeignKey to navigate into the real column (dangerous, since it is assuming) or get the comparison to honor proxy columns (more likely). if you can file a ticket that would be very helpful otherwise im going to forget. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Backrefs and the identity map
Michael Bayer wrote: King Simon-NFHD78 wrote: to master_id = sa.Column(sa.Integer, sa.ForeignKey(Master.__table__.c.id)) ...and now it seems to work! So is this a bug? yes, that would be a bug. There are some other scenarios where this kind of thing occurs (lazy clause doesn't optimize) related to inheritance but they are less clear cut as bugs. Another point though, if you upgrade to trunk /0.5.6, many-to-one backrefs wont even fire off anymore if unloaded, when they are accessed in the backref context. anyway my hunch is that the Column you get back from Master.id is a proxy to the real one, so we'd have to figure some way for ForeignKey to navigate into the real column (dangerous, since it is assuming) or get the comparison to honor proxy columns (more likely). if you can file a ticket that would be very helpful otherwise im going to forget. Done. In case it helps, the proxy is an sqlalchemy.sql.util.AnnotatedColumn. If you call '_deannotate' on it, the resulting object compares equal with the original column. Thanks again, Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: backrefs
On Jun 26, 2008, at 7:22 AM, [EMAIL PROTECTED] wrote: hi just an idea: is it possible to have half-baked backref-declarations? i want to use the SA's way of inventing backrefs from a name, and just provide some extra arguments to that invention. instead now i have a full backref(...) having more or less all of the relation(...) arguments, but with additional logic on picking/swapping of primaryjoin/secondaryjoin - something that SA does internaly in the PropertyLoader constructor. this sounds like you mean: x: relation(Foo, backref=somebackref, backref_primaryjoin=xx, backref_remote_site=x) ? btw remote_side is not propagated by PropertyLoader constructor - but IMO is needed. remote_side by definition cannot be the same on both sides of a relation. do you mean the backref should figure it out based on the forwards-facing explicit remote_side ? Actually I can't see how that would work, if SA can't figure out the forwards facing one I don't think it would be that great for it to try guessing the backwards facing one. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: backrefs
On Jun 26, 2008, at 1:22 PM, [EMAIL PROTECTED] wrote: sort of, x: relation( Foo, primaryjoin=, secondaryjoin=,remote_side=,whatever, backref= halfbackref(name=abc,post_update=True)) and let it construct the backref from relation.primary/secondaryjoin etc, putting name and whatever extra args are there. it already re-uses primaryjoin and secondaryjoin in 0.5 with the regular backref=foo, reversing primary/secondary if both are present. the rest of the args dont really propagate. remote_side by definition cannot be the same on both sides of a relation. do you mean the backref should figure it out based on the forwards-facing explicit remote_side ? yes, if there is explicit forward remote_side, the backward should be guessable. if that needs extra info like pjoins etc, so be it. heh, by definition... right now i'm giving same thing to both sides and it seems to work. but not really sure, i havent tested heavily the backref-using stuff. usually guessable is not really enough here. its definitely not always guessable. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
