Samuel, On 21. 9. 2016, at 1:24, Samuel Pelletier <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 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) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com >> >> This email sent to sam...@samkar.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