Actually, my coworker and I were discussing, if the foreign key is
specified, whether transient, pending (with autoflush off), or
persistent, you intuitively *expect* that referencing the attribute will
load the persistent related object.
The difficultly for sqlalchemy is that you have no idea what session to
pull it from. However, for many users, there is only one
(Scoped)Session at a time, so there is no ambiguity. In that case, I'd
argue the correct behavior is load the object/collection, if possible....
Thanks, it seems to be working now for me.
(The other expected behavior, which I hope to tackle, is that if you
change a foreign key reference and the ORM *knows* it is a foreign key
reference to a loaded relation, it should expire that relation... I've
asked you about that and you said it was a big undertaking... I wish I
understood why better, because my plan is to implement this for my
project and my hopes are that whatever has stopped you from doing so for
sqlalchemy won't be an issue for our use case)
On 9/10/2010 5:07 PM, Michael Bayer wrote:
I almost needed the exact same feature you have the other day. So I wouldn't
close the book on it. I just know that as default behavior, or even readily
switchable behavior, non-invested users get confused rather quickly.
On Sep 10, 2010, at 4:21 PM, Kent Bower wrote:
I've got a "fix" for our project. Python is really cool about letting you
reassign methods and functions, so I just reassigned
CollectionAttributeImpl._set_iterable to my own function.
The point is, for my sake, don't worry about a public API, unless others also
ask about it...
Thanks for your help.
On 9/10/2010 3:27 PM, Michael Bayer wrote:
Sent from my iPhone
On Sep 10, 2010, at 2:11 PM, Kent Bower<k...@retailarchitects.com> wrote:
I'm headed that direction now, thanks.
I didn't find anything on the wiki for how to plug in a subclassed
CollectionAttributeImpl, for example. I could hack it, but is there a public
or preferred way?
Well this is all entirely uncharted territory. Ideally there would be solid
public Apis for this stuff but especially in highly customized situations like
this, they need to be specified very carefully. It seems at least that the
lazy callables techniques might be further exposed.
this is a lot to review, and I'll try to get to it, but since you're digging
into internals anyway have you considered just creating your own AttributeImpl
subclasses ? You can then implement get()/set() and make it do whatever you'd
like.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@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.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@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.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@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.
