• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!?

  • Subject: Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!?
  • From: Chuck Hill <email@hidden>
  • Date: Fri, 27 Feb 2015 22:25:45 +0000
  • Thread-topic: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!?


On 2015-02-27, 2:22 PM, "OC" wrote:

Chuck,

On 27. 2. 2015, at 23:04, Chuck Hill <email@hidden> 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@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
  • Follow-Ups:
    • Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!?
      • From: OC <email@hidden>
References: 
 >in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!? (From: OC <email@hidden>)
 >Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!? (From: Chuck Hill <email@hidden>)
 >Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!? (From: OC <email@hidden>)
 >Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!? (From: Chuck Hill <email@hidden>)
 >Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!? (From: OC <email@hidden>)

  • Prev by Date: Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!?
  • Next by Date: first version of deployment config scripts for Ubuntu/AWS
  • Previous by thread: Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!?
  • Next by thread: Re: in another EC, when objects transferred through GIDs, owning relationship does not delete objects?!?
  • Index(es):
    • Date
    • Thread