Chuck,
On 27. 2. 2015, at 23:04, Chuck Hill <[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?
> 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?
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]
