Hi, I'm just mucking around with Pyro to see if I can use my
entity objects on both sides, even though only one side knows
anything about SQLAlchemy.

So my server is the instrumented side, and it does the actual database
access.

On my client, I create my objects, and try to call object_insert(o) on
my server.

I've tried a bunch of approaches, including instantiating a new object
on the server, and copying attributes over one by one to convert the
recently un-pickled non-instrumented object into one that I can use
in session.save(o)

The problem is that as soon as I try to access the non-instrumented
object on the instrumented side, I get the error
    object has no attribute '_state'

The one thing that I've found that does work is if the client doesn't
instantiate its own objects.  If the client asks the server for a new
(instrumented) object, then the client can make some changes and send
it back, and everything seems to work.

My goal is to keep the client side of the connection dumb about what
the
back-end really is... but if I cheat and instrument my objects on the
client side as well, I get the error:
   OrderedDict has no attribute '_list'

And I can't figure out what that is telling me.  I'm not getting
the full stack trace either, since the error is happening on the other
side of the RPC.

It does sound like the same issue (converting between Instrumented and
non-instrumented at will)  would help with some other poster's
problems
where they use pickle or some other mechanism to keep session state.

I've thought of mirroring my entire set of model classes with another
set that simply had different class names, so when one set was
instrumented
the other set was untouched... then I'd be able to copy between the
two on the server side as necessary.  I'm wondering if I used
inheritance
if that would solve it... I would only instrument the child class,
and leave all the data in the parent class.

class A:
   mydata='here'

class B(A):
   # instrumented, and still has data

Would that work?  Is there a way that after an unpickle of A, I could
convert it to an instance of instrumented B of some sort?

Or am I just missing a best-practices way of working with non-
instrumented
objects in one process, and RPCing them to an instrumented process?

Thanks!
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to