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.jpg>>
<<inline: image001.jpg>>
<<inline: image002.jpg>>
