On Sep 10, 2010, at 5:16 PM, Kent Bower wrote:
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.
I
I'm wondering if you think my use case is one you would like to
support, or if you think it is sort of off on its own (I could tell I
wasn't explaining our use case extremely well)...
Regardless, I am setting the InstrumentedAttribute's implementation's
callable_ so I have control over
On Sep 10, 2010, at 12:24 PM, Kent Bower wrote:
I'm wondering if you think my use case is one you would like to support, or
if you think it is sort of off on its own (I could tell I wasn't explaining
our use case extremely well)...
Regardless, I am setting the InstrumentedAttribute's
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
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
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
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
That is for comparing *Clauses* and handles:
locations.siteid = :param_1
and
:param_1 = locations.siteid
However,
locations.siteid = :param_1 AND locations.locationid = :param_2
and
locations.locationid = :param_1 AND locations.siteid = :param_2
are ClauseLists, which compares their individual
I've got a recipe for what will work well for us. I imagine it could
be useful for others, although I left out the actual serialization
mechanism, since that will likely be very project specific.
I'd be happy to put this on the wiki, but if you wanted to look it over
first, you are more
On Sep 8, 2010, at 2:34 PM, Kent Bower wrote:
That is for comparing *Clauses* and handles:
locations.siteid = :param_1
and
:param_1 = locations.siteid
However,
locations.siteid = :param_1 AND locations.locationid = :param_2
and
locations.locationid = :param_1 AND locations.siteid =
Mike, in your proof of concept, when __getstate__ detected transient,
why did you need to make a copy of self.__dict__? self.__dict__.copy()
On 9/6/2010 2:35 PM, Michael Bayer wrote:
On Sep 6, 2010, at 2:11 PM, Kent Bower wrote:
Also, I was hoping you would tell me whether this would be a
On Sep 7, 2010, at 10:12 AM, Kent Bower wrote:
Mike, in your proof of concept, when __getstate__ detected transient, why did
you need to make a copy of self.__dict__? self.__dict__.copy()
i was modifying the __dict__ from what would be expected in a non-serialized
object, so that was to
Don't want to strangle me, but when the orm (lazy)loads a MANYTONE
object, it doesn't go to the database if the object is in the session.
Can I get with_parent() to behave this way, or would I need to
specifically build up the primary key of the related object and call
query.get()?
On
On Sep 7, 2010, at 4:38 PM, Kent Bower wrote:
Don't want to strangle me, but when the orm (lazy)loads a MANYTONE object, it
doesn't go to the database if the object is in the session. Can I get
with_parent() to behave this way, or would I need to specifically build up
the primary key of
On Sep 7, 2010, at 6:41 PM, Kent Bower wrote:
Two items:
* How does the orm currently determine whether it is safe to try get() (e.i.
there are no funny join conditions)? If you point me to the function where
decision takes place, I can probably answer this myself
it compares the
On Sep 6, 2010, at 9:06 AM, Kent wrote:
with_parent seems to add a join condition. Is there a way to get at
the query object that would be rendered from a lazy load (or what
subqueryload would render on the subsequent load), but on a
transient object, if i supply the session?
with_parent()
On Sep 6, 2010, at 9:06 AM, Kent wrote:
with_parent seems to add a join condition.
OK, so I guess you read the docs which is why you thought it joined and why you
didn't realize it doesn't work for transient. r20b6ce05f194 changes all that
so that with_parent() accepts transient objects
Fantastic, I will like to look into this change.
Since you asked, consider a use case similar to this: we have a RESTfulish web
service that accepts a serialized version of a transfer object which is
passed to the server when a database save should take place. In this case, an
order with
On Sep 6, 2010, at 12:01 PM, Kent Bower wrote:
Fantastic, I will like to look into this change.
Since you asked, consider a use case similar to this: we have a RESTfulish
web service that accepts a serialized version of a transfer object which is
passed to the server when a database
On Sep 6, 2010, at 1:04 PM, Michael Bayer mike...@zzzcomputing.com wrote:
On Sep 6, 2010, at 12:01 PM, Kent Bower wrote:
Fantastic, I will like to look into this change.
Since you asked, consider a use case similar to this: we have a RESTfulish
web service that accepts a serialized
On Sep 6, 2010, at 1:04 PM, Michael Bayer wrote:
But there is good news, if we look at this for what it seems to be, which is
an optimized serialization scheme. You should build it that way. Write
custom serialization (__getstate__/__setstate__) for your class - if it
detects as
Actually, for my case, we are just serializing with json, we aren't
pickling it... We send the updated values back to the client as json
text. Later, the client will resend the final json serialized order
when it requests a 'save'. In other words, I don't need to worry about
the session
On Sep 6, 2010, at 3:54 PM, Kent Bower wrote:
Actually, for my case, we are just serializing with json, we aren't pickling
it... We send the updated values back to the client as json text. Later,
the client will resend the final json serialized order when it requests a
'save'. In
For the case of customerid = '7', that is a simple problem, but when
it is a more complex join condition, we only wanted to define this
condition in one single place in our application (namely, the orm).
That way, if or when that changes, developers don't need to search for
other places in the app
24 matches
Mail list logo
