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 or pickling it... the server is stateless.

Would that make a difference to your approach?


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 candidate for 
subclassing InstrumentedAttribute?  Would that make more sense or providing custom 
__getstate__&  __setstate__ ?
__getstate__ / __setstate__ are pretty much what I like to use for pickle 
stuff, unless some exotic situation makes me have to use __reduce__.   One 
problem with the recipe is that theres no 'deferred' loading of attributes.   
So in that sense playing with InstrumentedAttribute would give you a chance to 
put a callable in there that does what you want.

There is also the possibility that __setstate__ can load up callables into the 
instance_state using state.set_callable().   This is a callable that triggers 
when you access the attribute that is otherwise None.   There's a little bit of 
fanfare required to get that callable to assign to the attribute in the right 
way.   Attached is an example of that.   This is all a little more shaky since 
the state/callable API isn't really public.  Hasn't changed for awhile but 
there's no guarantee.







Thanks for your help, hopefully I'll be able to contribute such a recipe.

Kent



Since sqla won't load that for me in the case of transient, I need to load the 
relation manually (unless you feel like enhancing that as well).
its not an enhancement - it was a broken behavior that was specifically 
removed.   The transient object has no session, so therefore no SQL can be 
emitted - there's no context established.



Now I can manually emulate the obj being persistent with your changes for

On Sep 6, 2010, at 10:58 AM, Michael Bayer<mike...@zzzcomputing.com>  wrote:

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 and will do the "look at the 
attributes" thing.   The docs are updated as this method does use the lazy loader 
SQL mechanism, not a join.



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?

even though not "recommended", can it make sqla believe my transient
object is detached by setting its state key?

There are reasons i do not want to add this to the session and
disabling autoflush would also cause problems.



On Sep 3, 9:58 am, Michael Bayer<mike...@zzzcomputing.com>  wrote:
On Sep 3, 2010, at 9:36 AM, Kent wrote:

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 that needed to manually duplicate the logic of
the orm join condition.
If I supplied the DBSession to sqla, it would know how to create the
proper Query object for this lazyload.  Can you point me in the right
direction (even if where you point me is not currently part of the
public API)?
Query has the with_parent() method for this use case.





Thanks again,
Kent
--
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 
athttp://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.

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


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

Reply via email to