Hmmm...In my scenario, the item is created server-side and "pushed" via DataServiceTransaction as currently my Managed objects are read-only.
To get this to work, I never exposed the "setId()" on the client-side, only the server-side Java object. So it seems the copying is occurring server-side as well outside of normal read/writeExternal serialization methods. -Chris --- In [email protected], "Jeff Vroom" <[EMAIL PROTECTED]> wrote: > > Oh interesting I haven't run into this case before, but I think we do > still need the ability to set the property on the AS side at least. > When you create an item on the client, it might have a null or empty id. > When you commit that change, the server typically assigns an id. The > client gets returned a new instance of the same item with the populated > id which then need to copy over into the original instance. > > > > Jeff > > > > ________________________________ > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of chris_alme > Sent: Tuesday, December 11, 2007 11:05 AM > To: [email protected] > Subject: [flexcoders] Re: DataServiceTransaction auto-refresh issue > > > > Hi Jeff - > > Thanks for the response. > > For the class in question, I've implemented read/writeExternal on both > the Java and Actionscript sides in order to "hide" the db id on the > client side. It is still exposed via a getter, so this should take > care of any serialization issue, so I'm still confused? > > --- In [email protected] <mailto:flexcoders%40yahoogroups.com> > , "Jeff Vroom" <jvroom@> wrote: > > > > Each Java class needs to be serialized from ActionScript. Right now, > > this means exposing all properties using public get/set methods or > with > > a public field. Without a setter, it is hard to know exactly what > field > > to set when we deserialize a class. > > > > > > > > Jeff > > > > > > > > ________________________________ > > > > From: [email protected] <mailto:flexcoders%40yahoogroups.com> > [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> > ] On > > Behalf Of chris_alme > > Sent: Tuesday, December 11, 2007 7:46 AM > > To: [email protected] <mailto:flexcoders%40yahoogroups.com> > > Subject: [flexcoders] Re: DataServiceTransaction auto-refresh issue > > > > > > > > I've found a solution to this!!! Though I am a bit puzzled and would > > love to get more input on this... > > > > I noticed in the LCDS log that the "identity" specified in > > data-management-config.xml: > > > > > > <destination id="messageService"> > > <adapter ref="java-dao"> > > <properties> > > <source>messageAssembler</source> > > <scope>application</scope> > > <factory>spring</factory> > > <metadata> > > <identity property="id" type="java.lang.Integer" /> > > </metadata> > > </properties> > > </adapter> > > </destination> > > > > of the managed object sent to the client was coming back as null (see: > > {id=null}): > > > > > > [Flex] 12/11/2007 09:02:11.461 [DEBUG] [Message.Data.page_items] > Before > > invoke service: data-service > > incomingMessage: Flex Message (flex.data.messages.DataMessage) > > operation = page_items > > id = null > > clientId = 53492C9B-48AD-96DB-8C56-C9B9B8F61CB3 > > correlationId = > > destination = messageService > > messageId = CE15E11D-7D0A-9BEC-EDB0-C9BA32DC7D6B > > timestamp = 1197385331461 > > timeToLive = 0 > > body = {} > > hdr(DSEndpoint) = clario-amf-polling > > hdr(sequenceId) = 1 > > hdr(DSids) = > > [ > > {id=null} > > ] > > hdr(DSId) = A27E7099-4D18-5A3A-B7AD-71EBEFFF9EA1 > > > > Long story short, the "id" property of my server-side object was NOT > > writable. This is intended as it ties to the DB identity and is either > > set during construction or via hibernate during insert/retrieval > to/from > > the DB. > > I changed the "setId()" method to public, and everything works fine - > > updates are pushed to the client and my DataGrid updates accordingly. > > > > Though I question why this has to be writable? I want it to be > read-only > > to prevent tampering. Why must it be writable??? > > > > According to the Live Cycle docs: > > A Data Management Service destination contains one or more identity > > elements that you can use to designate data properties to be used to > > guarantee unique identity among items in a collection of data. > > So as long as I set the identity, shouldn't LCDS need only the ability > > to read it for comparison purposes??? I know it is getting set > properly > > as I can debug and see it prior to serialization. > > Thoughts??? > > >
