Re: EOF inserts already existing M:N relationships/empty snapshot?!?

[Chuck Hill]

I bet Alice was a developer too.

Have you overridden any of the EOF methods, or the generated methods in User or 
DataBlock and changed the normal behavior?  Or forgotten to call super?

From: OC 
Date: Tuesday, September 20, 2016 at 6:33 PM
To: Chuck Hill 
Cc: "webobjects-dev@lists.apple.com WebObjects" 
Subject: Re: EOF inserts already existing M:N relationships/empty snapshot?!?

Chuck,

On 21. 9. 2016, at 2:40, o...@ocs.cz wrote:

Aside of that, I have added a log into the 
DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot method, and 
here I *never* get *anything* for the relationships: neither the old (which is 
presumable) *nor the new* dictionary ever contain the “userDataBlocks” or 
“dataBlockUsers” key — not once.

well this one's weird, or I am missing something of importance here.

Meantime, I have played with another M:N, which works without a glitch (and 
which is modelled the same way as that one which does not, incidentally). Here, 
save-time, the snapshot does contain the proper related objects (and thus 
proper INSERTs are generated).

The weird thing is that these objects *do not* come into the snapshot through 
the DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot method! 
It logs all right when the object is fetched, but the new (nor the old, of 
course) dictionary does *not* contain the relationship key at all -- precisely 
the same way it is with that relationship which does not work properly!

Nevertheless, as mentioned above, save-time, the snapshot is all right. 
Couriouser and couriouser, Alice would say :-O

Thanks and all the best,
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/archive%40mail-archive.com

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

Re: EOF inserts already existing M:N relationships/empty snapshot?!?

[OC]

Chuck,

all my PKs/FKs are the same:
- "INTEGER" for SQL type
- "NSNumber" for class name
- "i" for value type

Thanks a big lot!
OC

On 21. 9. 2016, at 3:40, Chuck Hill  wrote:

> Off the top of my head, check they types of the keys to, as defined in the 
> EOModel, to the M:N table and in the M:N table.  Are all consistently Integer 
> or Long in Java?
>  
> Chuck
>  
>  
> From: OC 
> Date: Tuesday, September 20, 2016 at 6:33 PM
> To: Chuck Hill 
> Cc: "webobjects-dev@lists.apple.com WebObjects" 
> 
> Subject: Re: EOF inserts already existing M:N relationships/empty snapshot?!?
>  
> Chuck,
>  
> On 21. 9. 2016, at 2:40, o...@ocs.cz wrote:
>  
> Aside of that, I have added a log into the 
> DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot method, 
> and here I *never* get *anything* for the relationships: neither the old 
> (which is presumable) *nor the new* dictionary ever contain the 
> “userDataBlocks” or “dataBlockUsers” key — not once.
>  
> well this one's weird, or I am missing something of importance here.
>  
> Meantime, I have played with another M:N, which works without a glitch (and 
> which is modelled the same way as that one which does not, incidentally). 
> Here, save-time, the snapshot does contain the proper related objects (and 
> thus proper INSERTs are generated).
>  
> The weird thing is that these objects *do not* come into the snapshot through 
> the DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot 
> method! It logs all right when the object is fetched, but the new (nor the 
> old, of course) dictionary does *not* contain the relationship key at all -- 
> precisely the same way it is with that relationship which does not work 
> properly!
>  
> Nevertheless, as mentioned above, save-time, the snapshot is all right. 
> Couriouser and couriouser, Alice would say :-O
>  
> Thanks and all the best,
> 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/archive%40mail-archive.com

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

Re: EOF inserts already existing M:N relationships/empty snapshot?!?

[Chuck Hill]

Off the top of my head, check they types of the keys to, as defined in the 
EOModel, to the M:N table and in the M:N table.  Are all consistently Integer 
or Long in Java?

Chuck


From: OC 
Date: Tuesday, September 20, 2016 at 6:33 PM
To: Chuck Hill 
Cc: "webobjects-dev@lists.apple.com WebObjects" 
Subject: Re: EOF inserts already existing M:N relationships/empty snapshot?!?

Chuck,

On 21. 9. 2016, at 2:40, o...@ocs.cz wrote:

Aside of that, I have added a log into the 
DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot method, and 
here I *never* get *anything* for the relationships: neither the old (which is 
presumable) *nor the new* dictionary ever contain the “userDataBlocks” or 
“dataBlockUsers” key — not once.

well this one's weird, or I am missing something of importance here.

Meantime, I have played with another M:N, which works without a glitch (and 
which is modelled the same way as that one which does not, incidentally). Here, 
save-time, the snapshot does contain the proper related objects (and thus 
proper INSERTs are generated).

The weird thing is that these objects *do not* come into the snapshot through 
the DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot method! 
It logs all right when the object is fetched, but the new (nor the old, of 
course) dictionary does *not* contain the relationship key at all -- precisely 
the same way it is with that relationship which does not work properly!

Nevertheless, as mentioned above, save-time, the snapshot is all right. 
Couriouser and couriouser, Alice would say :-O

Thanks and all the best,
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/archive%40mail-archive.com

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

Re: EOF inserts already existing M:N relationships/empty snapshot?!?

[OC]

Chuck,

On 21. 9. 2016, at 2:40, o...@ocs.cz wrote:

> Aside of that, I have added a log into the 
> DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot method, 
> and here I *never* get *anything* for the relationships: neither the old 
> (which is presumable) *nor the new* dictionary ever contain the 
> “userDataBlocks” or “dataBlockUsers” key — not once.

well this one's weird, or I am missing something of importance here.

Meantime, I have played with another M:N, which works without a glitch (and 
which is modelled the same way as that one which does not, incidentally). Here, 
save-time, the snapshot does contain the proper related objects (and thus 
proper INSERTs are generated).

The weird thing is that these objects *do not* come into the snapshot through 
the DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot method! 
It logs all right when the object is fetched, but the new (nor the old, of 
course) dictionary does *not* contain the relationship key at all -- precisely 
the same way it is with that relationship which does not work properly!

Nevertheless, as mentioned above, save-time, the snapshot is all right. 
Couriouser and couriouser, Alice would say :-O

Thanks and all the best,
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/archive%40mail-archive.com

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

Re: EOF inserts already existing M:N relationships/empty snapshot?!?

[o...@ocs.cz]

Just a quick followup -- sorry, forgot to copy/paste the 2nd part of the log, 
though I fear it would not help much — it just confirms the user's snapshot 
does not get changed either:

> On 21. 9. 2016, at 2:40 AM, o...@ocs.cz wrote:
> 
> Chuck,
> 
>> On 20. 9. 2016, at 10:48 PM, Chuck Hill  wrote:
>> 
>> This is why they are getting inserted again:
>> 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:
>> 
>> It should not be an empty array.  EOF compares this and the relationship on 
>> the EO to determine what database operations are needed.
> 
> I see.
> 
>> I’d start with logging that out just after you fetch/fault currentUser into 
>> ec (you don’t show that below).  If it is empty there, then keep logging to 
>> see where the data disappears.  At this point, I am not ready to guess.
> 
> The thing seems empty all the time. Weird. Here's what I log fetch-time:
> 
> ===
> def cbc= // the business case whose users are about to be fetched
> println "### about to fetch $cbc...\noldSS 
> ${cbc.editingContext().committedSnapshotForObject(cbc).userDataBlocks}"
> def xxx=cbc.userDataBlocks()
> println "### -> did fetch $xxx\nnewSS 
> ${cbc.editingContext().committedSnapshotForObject(cbc).userDataBlocks}"
> xxx.each { println "### user $it\n### rel ${it.dataBlockUsers()}\n###   ss 
> ${it.editingContext().committedSnapshotForObject(it).dataBlockUsers}" }
> ===
> 
> Presumably, the “oldSS” should be empty, but the “newSS” should be a copy of 
> the relationship value (i.e., “cbc.userDataBlocks()”, or “xxx”)?
> 
> It is not; the snapshot consistently stays empty:
> 
> ===
> ### about to fetch  /EC:6350cea5>...
> oldSS []
> ### -> did fetch [, 
> ,  PK:109 T:'4' Name:'kl kl kl' /EC:6350cea5>]
> newSS []

### user 
### rel [, 
, 
, 
, 
, 
, 
, 
]
###   ss []

> ===
> 
> Aside of that, I have added a log into the 
> DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot method, 
> and here I *never* get *anything* for the relationships: neither the old 
> (which is presumable) *nor the new* dictionary ever contain the 
> “userDataBlocks” or “dataBlockUsers” key — not once.
> 
> Well it still might be a wrong model settings as Samuel suggests perhaps? But 
> it is sort of weird I use this settings for years and lots of M:N's, and this 
> is the first time I have bumped into this kind of problems.
> 
> Can you see what to check next?
> 
> Thanks a very big lot,
> OC
> 
>> 
>> Also, this is 100% consistent, right?  This is not a concurrency issue?
>> 
>> Chuck
>> 
>> 
>> From:  on behalf 
>> of "o...@ocs.cz" 
>> Date: Tuesday, September 20, 2016 at 11:50 AM
>> To: "webobjects-dev@lists.apple.com WebObjects" 
>> 
>> Subject: EOF inserts already existing M:N relationships/empty snapshot?!?
>> 
>> 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):
>> 
>> []
>> 
>> 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:
>> 
>> []
>> 
>> 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:
>> 
>> [, , 
>> , , 
>> , , 
>> , , 
>> ]
>> 
>> 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 th

Re: EOF inserts already existing M:N relationships/empty snapshot?!?

[o...@ocs.cz]

Chuck,

> On 20. 9. 2016, at 10:48 PM, Chuck Hill  wrote:
> 
> This is why they are getting inserted again:
> 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:
>  
> It should not be an empty array.  EOF compares this and the relationship on 
> the EO to determine what database operations are needed.

I see.

> I’d start with logging that out just after you fetch/fault currentUser into 
> ec (you don’t show that below).  If it is empty there, then keep logging to 
> see where the data disappears.  At this point, I am not ready to guess.

The thing seems empty all the time. Weird. Here's what I log fetch-time:

===
def cbc= // the business case whose users are about to be fetched
println "### about to fetch $cbc...\noldSS 
${cbc.editingContext().committedSnapshotForObject(cbc).userDataBlocks}"
def xxx=cbc.userDataBlocks()
println "### -> did fetch $xxx\nnewSS 
${cbc.editingContext().committedSnapshotForObject(cbc).userDataBlocks}"
xxx.each { println "### user $it\n### rel ${it.dataBlockUsers()}\n###   ss 
${it.editingContext().committedSnapshotForObject(it).dataBlockUsers}" }
===

Presumably, the “oldSS” should be empty, but the “newSS” should be a copy of 
the relationship value (i.e., “cbc.userDataBlocks()”, or “xxx”)?

It is not; the snapshot consistently stays empty:

===
### about to fetch ...
oldSS []
### -> did fetch [, 
, ]
newSS []
===

Aside of that, I have added a log into the 
DatabaseContextDelegate.databaseContextShouldUpdateCurrentSnapshot method, and 
here I *never* get *anything* for the relationships: neither the old (which is 
presumable) *nor the new* dictionary ever contain the “userDataBlocks” or 
“dataBlockUsers” key — not once.

Well it still might be a wrong model settings as Samuel suggests perhaps? But 
it is sort of weird I use this settings for years and lots of M:N's, and this 
is the first time I have bumped into this kind of problems.

Can you see what to check next?

Thanks a very big lot,
OC

>  
> Also, this is 100% consistent, right?  This is not a concurrency issue?
>  
> Chuck
>  
>  
> From:  on behalf 
> of "o...@ocs.cz" 
> Date: Tuesday, September 20, 2016 at 11:50 AM
> To: "webobjects-dev@lists.apple.com WebObjects" 
> 
> Subject: EOF inserts already existing M:N relationships/empty snapshot?!?
>  
> 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):
>  
> []
>  
> 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:
>  
> []
>  
> 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:
>  
> [, , 
> , , 
> , , 
> , , 
> ]
>  
> 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:142}
>- 2: INSERT on 'DB_UserDataBlock'  2{db_id:123, 
> user_id:105}
>- 3

Re: Cannot obtain globalId for an object which...

[Chuck Hill]

Does this only happen sometimes?  “the databaseContext's active editingContext” 
is referring to the active EC, which is transactional (e.g. set at the start of 
an EOF operation and cleared at the end).  If the code is calling into EOF 
without locking, it might result in this.

From: Ricardo Parada 
Date: Tuesday, September 20, 2016 at 3:19 PM
To: Chuck Hill 
Cc: "webobjects-dev@lists.apple.com" 
Subject: Re: Cannot obtain globalId for an object which...

Hi Chuck,

I followed the steps of the code and I noticed that the object containing the 
to-many relationship in question is being local instanced in a peer editing 
context. The to-many is still an array fault which has not been triggered.

Then when the object in the original context has its to-many triggered, i.e.  
by calling:

analysis.groupings().count();

Where analysis is the EO and groupings() is the to-many then the exception is 
generated.

It appears to have that if I trigger the to-many early on then the exception is 
avoided.

Anyways, I will experiment a little bit more with the problem and report back. 
I don't recall seeing something like this before and I local instance objects 
from one editing context to another all the time.

Thanks



On Sep 20, 2016, at 5:21 PM, Chuck Hill 
mailto:ch...@gevityinc.com>> wrote:
A full stack track would help.  It sounds like your code is making a 
relationship between objects in different editing contexts.  Did someone forget 
to add a “localInstance”?



From: 
mailto:webobjects-dev-bounces+chill=gevityinc@lists.apple.com>>
 on behalf of Ricardo Parada mailto:rpar...@mac.com>>
Date: Tuesday, September 20, 2016 at 2:18 PM
To: "webobjects-dev@lists.apple.com" 
mailto:webobjects-dev@lists.apple.com>>
Subject: Cannot obtain globalId for an object which...


Hi all,

All of a sudden one of our apps started getting this. Does anybody know why 
this would happen? It did not seem to have a problem before until now.

Cannot obtain globalId for an object which is registered in an other than the 
databaseContext's active editingContext,
object: ,
databaseContext: com.webobjects.eoaccess.EODatabaseContext@3935ae60,
object's editingContext: er.extensions.eof.ERXEC@4247ac26,
databaseContext's active editingContext: er.extensions.eof.ERXEC@c0fc23d’


 ___
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

Re: EOF inserts already existing M:N relationships/empty snapshot?!?

[Chuck Hill]

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:  on behalf of 
OC 
Date: Tuesday, September 20, 2016 at 5:22 PM
To: Samuel Pelletier 
Cc: "webobjects-dev@lists.apple.com WebObjects" 
Subject: Re: EOF inserts already existing M:N relationships/empty snapshot?!?

Samuel,

On 21. 9. 2016, at 1:24, Samuel Pelletier 
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 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):
[]
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:
[]
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:
[, , 
, , 
, , 
, , 
]
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:142}
  - 2: INSERT on 'DB_UserDataBlock'  2{db_id:123, 
user_id:105}
  - 3: INSERT on 'DB_UserDataBlock'  2{db_id:122, 
user_id:105}
  - 4: INSERT on 'DB_UserDataBlock'  2{db_id:103, 
user_id:105}
  - 5: INSERT on 'DB_UserDataBlock'  2{db_id:116, 
user_id:105}
  - 6: INSERT on 'DB_UserDataBlock'  2{db_id:142, 
user_id:105}
  - 7: INSERT on 'DB_UserDataBlock'  2{db_id:119, 
user_id:105}
  - 8: INSERT on 'DB_UserDataBlock'  2{db_id:129, 
user_id:105}
  - 9: INSERT on 'DB_UserDataBlock'  2{db_id:124, 
user_id:105}
  - 10: INSERT on 'DB_UserDataBlock'  2{db_id:133, 
user_id:105}
===
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 
fetch

Re: EOF inserts already existing M:N relationships/empty snapshot?!?

[OC]

Samuel,

On 21. 9. 2016, at 1:24, Samuel Pelletier  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):
>> 
>> []
>> 
>> 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:
>> 
>> []
>> 
>> 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:
>> 
>> [, , 
>> , , 
>> , , 
>> , , 
>> ]
>> 
>> 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:142}
>>  - 2: INSERT on 'DB_UserDataBlock'  2{db_id:123, 
>> user_id:105}
>>  - 3: INSERT on 'DB_UserDataBlock'  2{db_id:122, 
>> user_id:105}
>>  - 4: INSERT on 'DB_UserDataBlock'  2{db_id:103, 
>> user_id:105}
>>  - 5: INSERT on 'DB_UserDataBlock'  2{db_id:116, 
>> user_id:105}
>>  - 6: INSERT on 'DB_UserDataBlock'  2{db_id:142, 
>> user_id:105}
>>  - 7: INSERT on 'DB_UserDataBlock'  2{db_id:119, 
>> user_id:105}
>>  - 8: INSERT on 'DB_UserDataBlock'  2{db_id:129, 
>> user_id:105}
>>  - 9: INSERT on 'DB_UserDataBlock'  2{db_id:124, 
>> user_id:105}
>>  - 10: INSERT on 'DB_UserDataBlock'  2{db_id:133, 
>> user_id:105}
>> ===
>> 
>> 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 em

Re: EOF inserts already existing M:N relationships/empty snapshot?!?

[Samuel Pelletier]

OC,

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

These are tricky to correctly configure.

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.

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.

Samuel


> 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):
> 
> []
> 
> 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:
> 
> []
> 
> 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:
> 
> [, , 
> , , 
> , , 
> , , 
> ]
> 
> 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:142}
>   - 2: INSERT on 'DB_UserDataBlock'  2{db_id:123, 
> user_id:105}
>   - 3: INSERT on 'DB_UserDataBlock'  2{db_id:122, 
> user_id:105}
>   - 4: INSERT on 'DB_UserDataBlock'  2{db_id:103, 
> user_id:105}
>   - 5: INSERT on 'DB_UserDataBlock'  2{db_id:116, 
> user_id:105}
>   - 6: INSERT on 'DB_UserDataBlock'  2{db_id:142, 
> user_id:105}
>   - 7: INSERT on 'DB_UserDataBlock'  2{db_id:119, 
> user_id:105}
>   - 8: INSERT on 'DB_UserDataBlock'  2{db_id:129, 
> user_id:105}
>   - 9: INSERT on 'DB_UserDataBlock'  2{db_id:124, 
> user_id:105}
>   - 10: INSERT on 'DB_UserDataBlock'  2{db_id:133, 
> user_id:105}
> ===
> 
> 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
> 

Re: Cannot obtain globalId for an object which...

[Ricardo Parada]

Hi Chuck,

I followed the steps of the code and I noticed that the object containing the 
to-many relationship in question is being local instanced in a peer editing 
context. The to-many is still an array fault which has not been triggered. 

Then when the object in the original context has its to-many triggered, i.e.  
by calling:

analysis.groupings().count();

Where analysis is the EO and groupings() is the to-many then the exception is 
generated. 

It appears to have that if I trigger the to-many early on then the exception is 
avoided. 

Anyways, I will experiment a little bit more with the problem and report back. 
I don't recall seeing something like this before and I local instance objects 
from one editing context to another all the time. 

Thanks



> On Sep 20, 2016, at 5:21 PM, Chuck Hill  wrote:
> 
> A full stack track would help.  It sounds like your code is making a 
> relationship between objects in different editing contexts.  Did someone 
> forget to add a “localInstance”?
>  
>  
>  
> From:  on behalf 
> of Ricardo Parada 
> Date: Tuesday, September 20, 2016 at 2:18 PM
> To: "webobjects-dev@lists.apple.com" 
> Subject: Cannot obtain globalId for an object which...
>  
>  
> Hi all,
>  
> All of a sudden one of our apps started getting this. Does anybody know why 
> this would happen? It did not seem to have a problem before until now. 
>  
> Cannot obtain globalId for an object which is registered in an other than the 
> databaseContext's active editingContext, 
> object: , 
> databaseContext: com.webobjects.eoaccess.EODatabaseContext@3935ae60, 
> object's editingContext: er.extensions.eof.ERXEC@4247ac26, 
> databaseContext's active editingContext: er.extensions.eof.ERXEC@c0fc23d’
>  
>  
 ___
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

Re: Cannot obtain globalId for an object which...

[Chuck Hill]

A full stack track would help.  It sounds like your code is making a 
relationship between objects in different editing contexts.  Did someone forget 
to add a “localInstance”?



From:  on behalf of 
Ricardo Parada 
Date: Tuesday, September 20, 2016 at 2:18 PM
To: "webobjects-dev@lists.apple.com" 
Subject: Cannot obtain globalId for an object which...


Hi all,

All of a sudden one of our apps started getting this. Does anybody know why 
this would happen? It did not seem to have a problem before until now.

Cannot obtain globalId for an object which is registered in an other than the 
databaseContext's active editingContext,
object: ,
databaseContext: com.webobjects.eoaccess.EODatabaseContext@3935ae60,
object's editingContext: er.extensions.eof.ERXEC@4247ac26,
databaseContext's active editingContext: er.extensions.eof.ERXEC@c0fc23d’


 ___
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

Cannot obtain globalId for an object which...

[Ricardo Parada]

Hi all,

All of a sudden one of our apps started getting this. Does anybody know why 
this would happen? It did not seem to have a problem before until now. 

Cannot obtain globalId for an object which is registered in an other than the 
databaseContext's active editingContext, 
object: , 
databaseContext: com.webobjects.eoaccess.EODatabaseContext@3935ae60, 
object's editingContext: er.extensions.eof.ERXEC@4247ac26, 
databaseContext's active editingContext: er.extensions.eof.ERXEC@c0fc23d’


 ___
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

Re: EOF inserts already existing M:N relationships/empty snapshot?!?

[Chuck Hill]

This is why they are getting inserted again:
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:

It should not be an empty array.  EOF compares this and the relationship on the 
EO to determine what database operations are needed.  I’d start with logging 
that out just after you fetch/fault currentUser into ec (you don’t show that 
below).  If it is empty there, then keep logging to see where the data 
disappears.  At this point, I am not ready to guess.

Also, this is 100% consistent, right?  This is not a concurrency issue?

Chuck


From:  on behalf of 
"o...@ocs.cz" 
Date: Tuesday, September 20, 2016 at 11:50 AM
To: "webobjects-dev@lists.apple.com WebObjects" 
Subject: EOF inserts already existing M:N relationships/empty snapshot?!?

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):

[]

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:

[]

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:

[, , 
, , 
, , 
, , 
]

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:142}
   - 2: INSERT on 'DB_UserDataBlock'  2{db_id:123, 
user_id:105}
   - 3: INSERT on 'DB_UserDataBlock'  2{db_id:122, 
user_id:105}
   - 4: INSERT on 'DB_UserDataBlock'  2{db_id:103, 
user_id:105}
   - 5: INSERT on 'DB_UserDataBlock'  2{db_id:116, 
user_id:105}
   - 6: INSERT on 'DB_UserDataBlock'  2{db_id:142, 
user_id:105}
   - 7: INSERT on 'DB_UserDataBlock'  2{db_id:119, 
user_id:105}
   - 8: INSERT on 'DB_UserDataBlock'  2{db_id:129, 
user_id:105}
   - 9: INSERT on 'DB_UserDataBlock'  2{db_id:124, 
user_id:105}
   - 10: INSERT on 'DB_UserDataBlock'  2{db_id:133, 
user_id:105}
===

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.
We

Changes

[Mark Wardle]

I enclose some simple diffs for wonder 7 - snapshot.

The first is a simple typo but its presence is irritating my sensibilities in 
my log files.

diff --git 
a/Frameworks/Core/ERExtensions/Sources/er/extensions/appserver/navigation/ERXNavigationItem.java
 
b/Frameworks/Core/ERExtensions/Sources/er/extensions/appserver/navigation/ERXNavigationItem.java
index 055add3..6518077 100644
--- 
a/Frameworks/Core/ERExtensions/Sources/er/extensions/appserver/navigation/ERXNavigationItem.java
+++ 
b/Frameworks/Core/ERExtensions/Sources/er/extensions/appserver/navigation/ERXNavigationItem.java
@@ -225,7 +225,7 @@
}
}
else {
-   log.warn("For nav core object: {} and 
child binding: {} recieved binding object: {}", this, childrenBinding(), o);
+   log.warn("For nav core object: {} and 
child binding: {} received binding object: {}", this, childrenBinding(), o);
}
}
}


The other is a simple fix to navigation menu item, (ERExtensions) which ensures 
a generated URL stays secure if the current request is secure.

diff --git 
a/Frameworks/Core/ERExtensions/Sources/er/extensions/appserver/navigation/ERXNavigationMenuItem.java
 
b/Frameworks/Core/ERExtensions/Sources/er/extensions/appserver/navigation/ERXNavigationMenuItem.java
index 9165d30..03acd48 100644
--- 
a/Frameworks/Core/ERExtensions/Sources/er/extensions/appserver/navigation/ERXNavigationMenuItem.java
+++ 
b/Frameworks/Core/ERExtensions/Sources/er/extensions/appserver/navigation/ERXNavigationMenuItem.java
@@ -117,7 +117,7 @@
if(_linkDirectlyToDirectActions) {
NSMutableDictionary bindings = 
navigationItem().queryBindings().mutableClone();
bindings.setObjectForKey(context().contextID(), 
"__cid");
-   url = 
context().directActionURLForActionNamed(navigationItem().directActionName(), 
bindings);
+   url = 
context().directActionURLForActionNamed(navigationItem().directActionName(), 
bindings, ERXRequest.isRequestSecure(context().request()), false);
} else {
url = context().componentActionURL();
}



Thanks,

Mark


 ___
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

EOF inserts already existing M:N relationships/empty snapshot?!?

[o...@ocs.cz]

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):

[]

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:

[]

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:

[, , 
, , 
, , 
, , 
]

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:142}
   - 2: INSERT on 'DB_UserDataBlock'  2{db_id:123, 
user_id:105}
   - 3: INSERT on 'DB_UserDataBlock'  2{db_id:122, 
user_id:105}
   - 4: INSERT on 'DB_UserDataBlock'  2{db_id:103, 
user_id:105}
   - 5: INSERT on 'DB_UserDataBlock'  2{db_id:116, 
user_id:105}
   - 6: INSERT on 'DB_UserDataBlock'  2{db_id:142, 
user_id:105}
   - 7: INSERT on 'DB_UserDataBlock'  2{db_id:119, 
user_id:105}
   - 8: INSERT on 'DB_UserDataBlock'  2{db_id:129, 
user_id:105}
   - 9: INSERT on 'DB_UserDataBlock'  2{db_id:124, 
user_id:105}
   - 10: INSERT on 'DB_UserDataBlock'  2{db_id:133, 
user_id:105}
===

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/archive%40mail-archive.com

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