But when is it not set?  After fetching into the EC?  After faulting it in?  Is 
there there at first and then goes away?  There is a method in Wonder that can 
clear a to-many relationship, but that should make it a fault not an empty 
array.

You really DO find all of the best bugs!  :-)

Chuck


From: <webobjects-dev-bounces+chill=gevityinc....@lists.apple.com> on behalf of 
OC <o...@ocs.cz>
Date: Tuesday, September 20, 2016 at 5:22 PM
To: Samuel Pelletier <sam...@samkar.com>
Cc: "webobjects-dev@lists.apple.com WebObjects" <webobjects-dev@lists.apple.com>
Subject: Re: EOF inserts already existing M:N relationships/empty snapshot?!?

Samuel,

On 21. 9. 2016, at 1:24, Samuel Pelletier 
<sam...@samkar.com<mailto:sam...@samkar.com>> wrote:

Did you created the M:N relationship using the modeler or you created it 
manually ?

Manually (well through my own modeller, which boils down to precisely the same 
result). Nevertheless, I have done this umpteen times before; and this is the 
first time I have bumped into any problem.

Your situation may be caused by an improper flattened relationship settings. 
The flattened relationships should have nothing checked in the Advanced pane of 
the modeler.

I went trough my “EOModeller User Guide”, but alas, there does not seem to be a 
snapshot of the Advanced Relationship pane, so I am not sure what precisely has 
been in there. Owns Destination and Delete Rule, I guess?

On my models, I always create them with the modeler and the relationships to 
the inner entity does not have "own relationship" checked but have the 
"Propagate primary key" checked.

Anyway, to be sure, I have tried both combinations (“owsDestination” YES/NO and 
“propagatesPrimaryKey” YES/NO) in the relationship dictionary, to no avail — 
always the same result, the snapshot is not set.

Thanks a lot,
OC

Le 20 sept. 2016 à 14:50, o...@ocs.cz<mailto:o...@ocs.cz> a écrit :
Hello there,
I have a pretty common setup: entities User and DataBlock, an M:N relationship 
represented by an intermediate entity containing just the two keys, flattened 
on both sides. At both sides the relationships are appropriately flattened. Set 
to own destination+delete rule cascade.
The problem is, upon inserting a new DataBlock and its relationship to a 
current user, beside the two objects which should be inserted (the new 
DataBlock and the new relationship), relationships to other (old) DataBlocks, 
which were before simply _fetched_ for the current user (just to display the 
current state), get inserted too — which, of course, causes an integrity 
constraint violation “this PK already exists“.
My code looks essentially like this:
===
EOEditingContext ec= ...
DBDataBlock ndb=new DBDataBlock()
ec.insertObject(ndb)
ndb.addObjectToBothSidesOfRelationshipWithKey(currentUser,'dataBlockUsers')
// logs here, see below
ec.saveChanges()
===
Immediately before ec.saveChanges(), I log out
(a) ec.insertedObjects(), which contains only one object (I have overridden 
toString() to get the PK /and other attributes, removed here for conciseness/ 
of an EO):
[<DBDataBlock@79adaefa PK:null>]
this is all right, null PK means a newly added object, it's the very 'ndb' 
datablock I just have inserted and which I am now saving.
(b) contents of the flattened M:N relationship 'ndb.dataBlockUsers' from the 
DBDataBlock@79adaefa to DBUser, which looks like this:
[<DBUser@71b29988 PK:1000005>]
again, quite all right: only one related user, the currentUser which I have 
just added to the relationship.
(c) contents of the flattened M:N inverse relationship from the current user, 
which looks like this:
[<DBDataBlock@189f083a PK:1000003>, <DBDataBlock@1b47d247 PK:1000016>, 
<DBDataBlock@5f927095 PK:1000019>, <DBDataBlock@54edfe4c PK:1000022>, 
<DBDataBlock@35e1e59c PK:1000023>, <DBDataBlock@793b3d6d PK:1000024>, 
<DBDataBlock@7b06dee8 PK:1000029>, <DBDataBlock@2550aab9 PK:1000033>, 
<DBDataBlock@79adaefa PK:null>]
for the third time, all right: 8 of them previously fetched, already existing 
relationships to other (old) datablocks for the current user, plus one new 
relationship to the newly added DBDataBlock@79adaefa. Perfect so far.
At this moment, ec.saveChanges is performed. I log the database operations from 
databaseContextWillPerformAdaptorOperations delegate method, and it looks like 
this:
===
-IN-adaptorOps === SPC: about to perform 10 DB operations     |19:54:37.061 
20.9.16|WorkerThread1
              - 1: INSERT on 'DBDataBlock'  1{uid:1000042}
              - 2: INSERT on 'DB_UserDataBlock'  2{db_id:1000023, 
user_id:1000005}
              - 3: INSERT on 'DB_UserDataBlock'  2{db_id:1000022, 
user_id:1000005}
              - 4: INSERT on 'DB_UserDataBlock'  2{db_id:1000003, 
user_id:1000005}
              - 5: INSERT on 'DB_UserDataBlock'  2{db_id:1000016, 
user_id:1000005}
              - 6: INSERT on 'DB_UserDataBlock'  2{db_id:1000042, 
user_id:1000005}
              - 7: INSERT on 'DB_UserDataBlock'  2{db_id:1000019, 
user_id:1000005}
              - 8: INSERT on 'DB_UserDataBlock'  2{db_id:1000029, 
user_id:1000005}
              - 9: INSERT on 'DB_UserDataBlock'  2{db_id:1000024, 
user_id:1000005}
              - 10: INSERT on 'DB_UserDataBlock'  2{db_id:1000033, 
user_id:1000005}
===
i.e., along with inserting the two new objects (1: the new datablock, 6: the 
new relationship), EOF for some darned reason decides to insert _also_ all 
those relationship objects it _fetched_ before! Of course, since they were 
fetched, they already exist in the database, and thus cause an integrity 
constraint violation “this PK already exists“.
Well, logging out 
"currentUser.editingContext().committedSnapshotForObject(currentUser)['userDataBlock']"
 before saveChanges, I get an empty array. I must admit I don't know whether 
there should be the relationship objects in this snapshot, but anyway:
- if not, I have no idea where to find the culprit;
- if yes, well, the culprit of those inserts is explained, but why on earth the 
snapshot is not properly maintained by EOF?!?
Any idea what might be the culprit, or at least, how to find it? I am afraid I 
am rather out of ideas :/
Thanks a lot,
OC
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      
(Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com
This email sent to sam...@samkar.com<mailto:sam...@samkar.com>


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      
(Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com

This email sent to ch...@gevityinc.com<mailto:ch...@gevityinc.com>
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to