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, "simonjpalmer" <[EMAIL PROTECTED]>
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, "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:[EMAIL PROTECTED] On
> > Behalf Of simonjpalmer
> > Sent: Tuesday, April 17, 2007 7:20 AM
> > To: flexcoders@yahoogroups.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
> >
>
