On 10/23/15 5:41 AM, [email protected] wrote: > > > On Thursday, October 22, 2015 at 2:57:32 PM UTC+1, Michael Bayer wrote: > > > > On 10/22/15 7:22 AM, [email protected] <javascript:> wrote: > > Hi, > > > > I've been trying to unravel some spaghetti code by using > bindparams in > > relationships, which at first seemed like a neat solution to my > > problems. Unfortunately, it seems to have some behaviour that I find > > erratic or unpredictable. I'm sure it's perfectly explicable, but I'd > > like to be able to know why things happen this way and what > precautions > > I could take to avoid problems. > > > > Long story short, we have some relationships that I'd like to eager > > load, but provide load parameters based on information I can gather > > during an http request. There's a callable the bindparam will > check that > > will respond with the right information if a Flask request context is > > present. I would obviously expect the joined object not to be there > > outside a request context, but even when the information is provided > > from the callable, committing the parent object will make the joined > > object unavailable. > > the call to commit() expires all attributes on all objects. When you > access it, it lazyloads, and the bound parameter value is gone. > Turning on echo=True on the engine will illustrate all of these things > happening. > > > > Thanks, that does explain a lot. Why isn't the callable used again when > lazy loading the object? If I configure the relationship to be lazy to > begin with, it does exactly what I expect, so why doesn't that happen > after a refresh?
oh, it looks like you're actually putting a callable_ in the bound parameter, I thought you were using query.params. Simple answer is that this use case has never been explored before and on line 591 of lib/sqlalchemy/orm/strategies.py the lazy clause generation cancels out the parameter. https://bitbucket.org/zzzeek/sqlalchemy/issues/3562/support-callable-boundparam-in-primaryjoin is added to eventually look into adding support for this case, thanks! > > > > > > > > I've written a working simplified test case > > here: https://gist.github.com/ctolsen/a122e8ed95e4e305a433 > <https://gist.github.com/ctolsen/a122e8ed95e4e305a433> > > One of these just use sqlalchemy, the other one demonstrates the > > behaviour with Flask (which is just about the same, but > demonstrates the > > callable returning None or a value). > > > > What's happening here and why? Should I be doing something > differently? > > Can I do something to make sure the joined object will always be > available? > > Thanks a bunch! > > > > Chris > > > > -- > > 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 [email protected] <javascript:> > > <mailto:[email protected] <javascript:>>. > > To post to this group, send email to [email protected] > <javascript:> > > <mailto:[email protected] <javascript:>>. > > Visit this group at http://groups.google.com/group/sqlalchemy > <http://groups.google.com/group/sqlalchemy>. > > For more options, visit https://groups.google.com/d/optout > <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 [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
