thanks, that did it, I now have copious debug logs. Onto fence two...
--- In flexcoders@yahoogroups.com, "Jeff Vroom" <[EMAIL PROTECTED]> wrote:
>
> That certainly looks right to me. That version of ConsoleTarget just
> uses the System.out to print messages so you might look around to see if
> they are going into a separate log file. You might try changing
> ConsoleTarget to ServletLogTarget which uses the Servlet's log method.
> That sometimes works better on app servers which like to redirect
> System.out to some other log file.
>
>
>
> Jeff
>
>
>
> ________________________________
>
> From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
> Behalf Of simonjpalmer
> Sent: Thursday, May 03, 2007 10:41 AM
> To: flexcoders@yahoogroups.com
> Subject: [flexcoders] Re: Help! Object integrity across
> DataService.commit()
>
>
>
> Jeff,
>
> I have fallen at the first fence trying to switch on the debug logs.
> I presumed this happened in the logging section of
> services-config.xml, so this is what I did:
>
> <logging>
> <target class="flex.messaging.log.ConsoleTarget" level="Debug">
> <properties>
> <prefix>[Flex] </prefix>
> <includeDate>false</includeDate>
> <includeTime>false</includeTime>
> <includeLevel>false</includeLevel>
> <includeCategory>false</includeCategory>
> </properties>
> <filters>
> <pattern>Endpoint.*</pattern>
> <pattern>Service.*</pattern>
> <pattern>Configuration</pattern>
> <pattern>DataService.*</pattern>
> <pattern>Message.*</pattern>
> </filters>
> </target>
> </logging>
>
> then I started my server and did some things through my UI which cause
> data to be read/written. I was watching my server stdout through a
> console and saw no additional messages. So I went to my server log
> which is where teh rest of my debug logging shows up to see what I
> got. Unfortunately I have nothing more than I was previously getting.
>
> What have I done wrong? Where should I be looking? Have I put the
> patterns in the config file correctly?
>
> If you would repfer to take this off flexcoders I can get in touch
> directly or you can email me simon.palmer @ gmail.com
>
> Simon
>
> --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com>
> , "simonjpalmer" <simonjpalmer@>
> wrote:
> >
> > Jeff,
> >
> > thank you for your response, I realaly appreciate it, this is driving
> > me slightly mad and there's a lot in here for me to try. Thanks also
> > for the offer of help decoding the logs, I may well take you up on
> > that. It's going to take me a couple of days to get into a position
> > to try this out properly but I will be back...
> >
> > Regards
> > Simon
> >
> > --- In flexcoders@yahoogroups.com
> <mailto:flexcoders%40yahoogroups.com> , "Jeff Vroom" <jvroom@> wrote:
> > >
> > > One of the features of Data Management is that the assembler can
> modify
> > > the objects involved in a create or an update. After the commit,
> these
> > > changes are applied to the managed copy. One common change made
> on the
> > > server is that during the create the server assigns new ids to the
> newly
> > > created items. If the assembler does not make any changes, nothing
> > > should be changed after the commit.
> > >
> > >
> > >
> > > So I think the first step would be to turn on the debug level for
> the
> > > "Message.*" and "DataService.*" patterns in the server logs, and
> compare
> > > the before and after "create" and "update" events in the logs.
> For lazy
> > > associations, the state of the association properties is stored in
> the
> > > "referencedIds" headers in the messages. For non-lazy
> associations, if
> > > you put toString methods in your DTOs to dump out relevant info
> that is
> > > helpful.
> > >
> > >
> > >
> > > One more thing to try that may help. When the objects have
> lazy="true"
> > > (not the default) only the references to objects are updated. At
> most,
> > > data management has to update references to objects so the instances
> > > would only change if the ids were changed. When lazy="false" we
> > > recursively update the object graph for the properties changed
> which is
> > > more involved so you might try adding lazy="true". In particular,
> make
> > > sure that parent has lazy="true" as backptrs tend to perform and
> behave
> > > better when you are not sending the parent's state along with an
> update
> > > of the child. This does sometimes mean you have to catch and ignore
> > > ItemPendingErrors but usually this doesn't happen for parents.
> > >
> > >
> > >
> > > If you could use help analyzing the logs, send them along. Sometimes
> > > the client side debug log is useful in these situations too
> > > (<mx:TraceTarget/>).
> > >
> > >
> > >
> > > Jeff
> > >
> > >
> > >
> > > ________________________________
> > >
> > > From: flexcoders@yahoogroups.com
> <mailto:flexcoders%40yahoogroups.com>
> [mailto:flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com>
> ] On
> > > Behalf Of simonjpalmer
> > > Sent: Tuesday, April 17, 2007 7:20 AM
> > > To: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com>
>
> > > Subject: [flexcoders] Help! Object integrity across
> DataService.commit()
> > >
> > >
> > >
> > > I seem to be getting object instances changing across a commit()
> > > boundary. Half the object ID's change through a commit for no
> > > apparent reason. This means I have no capability to manage a
> > > parent-child relationship in data. Utter disaster!
> > >
> > > Here's the situation. I have a parent child hierarchy of objects,
> > > from the root to the leaves:
> > > PO
> > > PP
> > > SS
> > > SC
> > > OP
> > > So PO's contain PP's, PP's contain SS's and so forth.
> > >
> > > I converse with a single data service which delivers a set of PO's
> and
> > > the PP's are thereafter lazily loaded. I don't break the dataservice
> > > or object model anywhere below that, so a PP is treated as a single
> > > entity and read and written as such with its entire sub-graph of
> > > objects.
> > >
> > > I have two destinations, one for PO's and one for PP's and this all
> > > works fine.
> > >
> > > However, when I create a graph such as the one above and commit it
> to
> > > the server through the PO destination I have different object
> > > instances for SS, SC and OP's after the call to commit returns.
> > >
> > > This is a problem because there are some properties which are
> specific
> > > to the object instance, in particular an object reference to its
> > > parent. The object instance of the parent is changing across the
> > > commit boundary.
> > >
> > > Before commit everything is joined up nicely as you would expect:
> > >
> > > PO @42f2451
> > > PP @43f3629 parent @42f2451
> > > SS @4c0ee71 parent @43f3629
> > > SC @a5d69d1 parent @4c0ee71
> > > OP @a2f5a01 parent @a5d69d1
> > >
> > > after commit these are the same...
> > >
> > > PO @42f2451
> > > PP @43f3629 parent @42f2451
> > >
> > > however everything else is different
> > >
> > > SS @4c0e151 parent @a94d3d1
> > > SC @4ba2d31 parent @4c0e151
> > > OP @<new> parent @4ba2d31
> > >
> > > what's worse is that the new parent instance of PP held on the new
> SS
> > > (i.e. whatever is under @a94d3d1) has itself a null parent
> reference.
> > > That means that after the commit my tree below SS is dangling in the
> > > wind and I cannot find the parentage up to PO!
> > >
> > > This is a complete disaster. It effectively means I have no
> > > bi-directional one-to-many support, e.g. no Parent-Child, the most
> > > basic of relationships!
> > >
> > > Worse, if I traverse down from PO to OP I cannot traverse back up
> > > again! It goes down one path and up another which ends before it
> gets
> > > to PO.
> > >
> > > So I have three questions:
> > >
> > > What am I doing wrong?
> > > How do I prevent my object instances from being screwed around with
> > > during commit?
> > > How do I tell when commit() has finished? Is there an Event I can
> > > trap for its completion? Then I could at least repair my tree.
> > >
> > > very glum...
> > >
> > > SP
> > >
> >
>
