On Oct 28, 2011, at 3:16 PM, Burak Arslan wrote:
>
> the link I provided has both the client and server implementations to
> reproduce the issue, maybe you didn't scroll up?
Did not scroll up, no. So looking at the sample code here, it's entirely a
mystery to me how this is even supposed to work; the mappings are not recreated
in any way I'm familiar with in ws_client.py. It does appear like there's some
major magic going on in rpclib/model/table.py to accomplish this. One thing
I'd note is that its usually better not to rely on declarative, which is only
syntactical sugar, to get information about a mapping - the Table and mapper()
structure contain all the information. Basing this system on declarative for
introspection is already brittle.
Anyway whatever magic in rpclib is somehow recreating the mappings in a new
process isn't doing the job correctly. It's creating two Patient classes with
mismatched state. The codepath being reached is only present for the edge
case that a subclass of a superclass is not mapped, but then in this case the
class manager is doubled up somehow.
Usually when I've dealt with RPC types of systems, the classes that are used on
the client are statically available, not dynamically reconstructed - that might
be a much more reliable approach here.
Here's how to reproduce:
from sqlalchemy import *
from sqlalchemy.ext.declarative import declarative_base
Base= declarative_base()
class A(Base):
__tablename__ = "a"
id = Column(Integer, primary_key=True)
class B(A):
# this just means, "dont map the class".
# A is mapped but B is not
__abstract__ = True
B._sa_class_manager = A._sa_class_manager
B()
>
> you can use suds the soap client or use curl wget etc. to perform a HTTP POST
> with the following data to http://localhost:7789/
>
> <SOAP-ENV:Envelope xmlns:ns0="com.mydomain.mobile"
> xmlns:xs="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:ns1="http://schemas.xml
> soap.org/soap/envelope/"
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";>
> <SOAP-ENV:Header/>
> <ns1:Body>
> <ns0:tpz_setPatients>
> <ns0:patients>
> <ns0:some_string>qwerty</ns0:some_string>
> <ns0:id>888</ns0:id>
> </ns0:patients>
> </ns0:tpz_setPatients>
> </ns1:Body>
> </SOAP-ENV:Envelope>
>
> hope that helps,
> burak
>
>
>
>
>> On Oct 28, 2011, at 12:30 PM, Burak Arslan wrote:
>>
>>> hi,
>>>
>>> any ideas on what could be the cause of the following backtrace here?
>>> https://gist.github.com/1322636#comments. this is probably something
>>> i'll need to fix in rpclib code, but I don't see what causes this.
>>>
>>> sqlalchemy version is latest trunk from today. the backtrace is one line
>>> off because of a comment, no change in source code around there.
>>>
>>> thanks,
>>> burak
>>>
>>> --
>>> 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
>>> 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 sqlalchemy@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 sqlalchemy@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.
