Hi Greg,
Yeah, thanks for sending this as it did uncover an LC DS bug. It occurs with
the combination of the deleteItem and the commit(item) or commit([item])
case. The code is trying to look up the DataService associated with the item
in the argument... to do that we look in the cache for each item. We can't
find it (since it has been deleted) and the code is improperly returning the
last data service in the list. So when it works, it is because the list of
data services is generated in some particularly lucky order.
If you can commit everything - not just that item, that would be an easy
workaround though most likely you are using that variant of commit for a reason.
I'll contact you off-list to get you a patched fds.swc to try out the fix.
For your reference, the bug number I filed is:
https://bugs.adobe.com/jira/browse/LCDS-351
Jeff
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of
gordon_greg
Sent: Thursday, July 03, 2008 12:53 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] LCDS: Problem with destination inheritance
Hello,
I'm using the latest LCDS 2.6.RC1 with the HibernateAssembler and a
non-trivial data model that relies upon destination inheritance in a
few places.
In general everything works great, but occasionally, when I remove an
element from a collection using dataService.deleteItem, when I then
call dataService.commit, I end up with an exception that indicates
that the wrong destination is being invoked...
For our purposes, let's just deal with 4 destinations:
Folder
ResourceFolder (extends folder)
Meeting
MeetingParticipant (is a many-to-one child of Meeting)
Now, if I call:
meetingParticipantDataService.deleteItem(meetingParticipant);
meetingParticipantDataService.commit([meetingParticipant],true);
I end up with the following exception:
== begin exception
Error: Destination: spring.folder received an instance of class:
demo.model.meetings::MeetingParticipant but we could not find a
destination in the list of sub-types: spring.resourceFolder which
extends this destination.
at
mx.data::ConcreteDataService/http://www.adobe.com/2006/flex/mx/internal::getDestinationForInstance()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:5309]
at
mx.data::ConcreteDataService/http://www.adobe.com/2006/flex/mx/internal::getItemDestination()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:5290]
at
mx.data::ConcreteDataService/http://www.adobe.com/2006/flex/mx/internal::getItemMetadata()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:5275]
at
mx.data::MessageBatch/addMessageIdsForItem()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\MessageBatch.as:591]
at
mx.data::MessageBatch/extractMessages()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\MessageBatch.as:456]
at
mx.data::DataStore/http://www.adobe.com/2006/flex/mx/internal::doCommit()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\DataStore.as:1807]
at
mx.data::DataStore/http://www.adobe.com/2006/flex/mx/internal::internalCommit()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\DataStore.as:818]
at
mx.data::ConcreteDataService/commit()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:337]
at
mx.data.mxml::DataService/commit()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\mxml\DataService.as:433]
at [my code here]
== end exception
Note that there is no relationship at all between MeetingParticipant
and Folder - they are completely independent of each other.
This feels like a bug to me, because it doesn't always happen, is not
reliable reproduced, and once it does happen it keeps happening until
I clean out my browser's cache.
Somehow, something gets the DataService layer in an unstable state,
possibly as a side effect of some exception being thrown somewhere in
my application (although this isn't clear either), and once it is in
that state, it doesn't recover.
Is anyone else seeing this? Should I be reporting this as a bug?
I'd be happy to provide more information as necessary.
Thanks.
inline: ~WRD000.jpginline: image001.jpginline: image002.jpg
