On 2015-02-27, 2:22 PM, "OC" wrote:
Chuck, On 27. 2. 2015, at 23:04, Chuck Hill <[email protected]<mailto:[email protected]>> wrote: You can't pass EOs to a background thread. You need to pass EOGlobalIDs to your runnable constructor instead and then create your new ec on the background thread when you begin processing. Your constructor is passing full EOs and thus you are getting weird behavior. You can pass in EOs *if* you don't keep a reference to them (e.g. If you just localInstance them and then discard the reference before the thread runs as you are doing). Holding references is problem as then two threads can cause changes, get hung up on locks etc. Hmmm, I might be again overlooking something of importance, but... given the original objects are in the session's default EC, I think there's no point in flushing the references, for whenever I get the object again (e.g., through a relationship, or through a fetch, whatever), due to uniquing I'll get again the same reference, will I not? I mean you can't stash the EO in the EC that your background thread does NOT own (e.g. The session's default editing context) in an ivar in the background thread. That is the danger of passing in an EO - someone will do that and then you have two threads touching the session's default EC. Passing in the global ID is safer as you can never do it wrong. OK, so I'll keep that code unchanged :) For the rest of the problem below, I am just shaking my head in amazement. Do you have any validateForDelete methods in your code? Nope. (Well I found one -- out-commented, in my DBUser class, and it looks like this: // void validateForDelete { // throw new NSValidation.ValidationException("Cannot delete users for the moment, sorry!") // } To be entirely frank I can't recall the reason it was there -- it must be long long time ago I commented it out, not speaking of when I wrote it :)) Anyway -- it _should_ work, right? It is not a weird behaviour of EOF, but something fishy in my application, which makes it not work? That is fine. I was wondering if you had code in validateForDelete that might be fetching or otherwise altering the object graph and confusing the EOF state. Chuck thanks a lot, OC I am able to repeat the problem e.g., this way: === launched very early in Application, no session/component created yet === def ec=ERXEC.newEditingContext() def auction=EOUtilities.objectWithPrimaryKeyValue(ec,'DBAuction',1000003) def records=auction.importedRecords() println "owning rel: ${auction.ownsDestinationObjectsForRelationshipKey('importedRecords')} inverse '${auction.inverseForRelationshipKey('importedRecords')}' #$records.count" // just to make sure it's all right def lr=records.lastObject() println "-- in 'default' EC removing $lr from $auction..." lr.removeObjectFromBothSidesOfRelationshipWithKey(auction,'auction') auction.editingContext().saveChanges() // my delegate logs out all adaptor ops: this does delete all right def ec2=ERXEC.newEditingContext(new EOObjectStoreCoordinator()) auction=ec2.faultForGlobalID(auction.permanentGlobalID(),ec2) // this is how I 'move' objects to background tasks... lr=ec2.faultForGlobalID(records.lastObject().permanentGlobalID(),ec2) // ... is it indeed the right way? println "-- in EC in extra OSC removing $lr from $auction..." lr.removeObjectFromBothSidesOfRelationshipWithKey(auction,'auction') auction.editingContext().saveChanges() // for this one DOES NOT delete, see the logs below! === This code -- along with the logs in databaseContextWillPerformAdaptorOperations -- prints out this: === owning rel: true inverse 'auction' #2 -- in 'default' EC removing <DBRecord@1532707037 PK:1004656 /EC:829232957> from <DBAuction@357286753 PK:1000003 /EC:829232957>... - 1: DELETE on 'DBRecord' (uid = 1004656) -- in EC in extra OSC removing <DBRecord@2038388710 PK:1004657 /EC:489384291> from <DBAuction@325329592 PK:1000003 /EC:489384291>... - 1: UPDATE on 'DBRecord' (uid = 1004657) 1{auction_id:<com.webobjects.foundation.NSKeyValueCoding$Null>} === Does it make any sense? It is already removed, so it does not remove it again? There were two objects in the auction.importedRecords relationship. First, I've removed records.lastObject, the one with PK:1004656. Since it was removed, records.lastObject was the remaining one, the one with PK:1004657. The same code -- but in another EC -- though did not remove it, though the relatioship is still owning... Thanks a lot, OC
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
