Chuck, On 27. 2. 2015, at 5:39, Chuck Hill <[email protected]> wrote:
> You? A weird problem? I am SHOCKED! :-) :) >> I've noticed lately that my background tasks (each of which uses its own EC) >> stopped to delete old objects. Pursuing the culprit, I have found that it >> began when I (by Ramsey's advice) stopped moving objects betwixt those ECs >> using localInstanceIn, > > Why was that? Why was what? That I originally used localInstanceIn? For the task uses own EC, different from the default one. That I switched to GIDs? For Ramsey knows EOF much better than me, and === On Jan 29, 2015, at 9:41 AM, OC <[email protected]> wrote: > static ERXLongResponseTask csvTask(EOEnterpriseObject ownerEO) { > ERXEC ec=ERXEC.newEditingContext() > ec.lock() // do I really need to lock here? > try { > ownerEO=ownerEO.localInstanceIn(ec) > } finally { > ec.unlock() > } > def task=new ImportCSVTask(ownerEO:ownerEO) > task.start() > task > } On 29. 1. 2015, at 18:00, Ramsey Gurley <[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. On 29. 1. 2015, at 19:05, Ramsey Gurley <[email protected]> wrote: > You should do something like > > ERXLongResponse csvTask(ERXGenericRecord eo) { > EOGlobalID gid = eo.permanentGlobalID(); > ImportCSVTask task = new ImportCSVTask(gid); > ... > } > > class ImportCSVTask { > private EOGlobalID _gid; > > ImportCSVTask(EOGlobalID gid) { > _gid = gid; > } > > performAction() { > //Safe here. Method called by the background thread > EOEditingContext ec = ERXEC.newEditingContext(); > EOEnterpriseObject eo = > ERXEOGlobalIDUtilities.fetchObjectWithGlobalID(ec, _gid); > //Do stuff > } > } > > You grab the gid, pass it to the runner, then when the background thread > calls run() on the runner, return the gid to an eo. Use wonder classes to do > this like the ERXLongResponseTask mentioned or an ERXRunnable since those do > the auto locking magic for you. === Now, is that wrong? I am now using that approach, and my only digress is using faultForGlobalID instead of ERXEOGlobalIDUtilities.fetchObjectWithGlobalID. >> 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]
