"Conflicting values in rows" throws general Error

[jtuchel]

In our production system we get "Inconsistent values in rows" from time to time when we save updated objects in a UnitOfWork. It is thrown in FieldValueWrapper>>#unifyWith:
Needless to say: I have never managed to get this error in a dev image...

First, we have no idea what could cause these problems. It currently seems as if these "just happen from time to time" with no obivous pattern. I have the feeling that is not true, but we've been hunting for a while now - without success. So if anybody has an idea what can cause these problems, please let me know.

Second, we'd like to add some walback output for these situations, so we can possibly learn more about the situation. For this it would be nice if we could catch this error.

Unfortunately, and as I have stated before, Glorp is not a great example of how to throw and catch exceptions. The failing method throws a generel Error instance instead of a GlorpError subclass.

I'd like to suggest replacing this with a specialized Error, most likely a new subclass of GlorpError, so that we can catch and handle just this problem.

• What do people think of this Class name: GlorpUpdateConflictError? What parameters would
  
• How can I suggest this to Glorp maintainers?

I've implemented a first idea of this in VA Smalltalk, how can I feed this back and discuss it with Glorp maintainers?

The implementation simply introduces a new Subclass of GlorpError and I changed FieldValueWrapper>>#unifyWith: with:

unifyWith: targetWrapper
    (self containsWrapper: targetWrapper) ifTrue: [^self].
    (targetWrapper containsWrapper: self) ifTrue: [^self].
    targetWrapper hasValue ifFalse: [^targetWrapper replaceWith: self].
    self hasValue ifFalse: [^self replaceWith: targetWrapper].
    self contents = targetWrapper contents
        ifFalse: [GlorpUpdateConflictError signal: ('Conflicting values in rows (location: FieldValueWrapper>>#unifyWith:) self=%1 target=%2' bindWith: self contents asString with: targetWrapper contents asString)].
    targetWrapper replaceWith: self.

What do people think of this? What would you store in this error object for debugging/analyisng the problem.

It enables us to catch this error individually and write a walback file with some history of the problem.

Joachim

[pma...@gmail.com]

Hi Joachim,

 

We do run into this error from time to time. In our case, until now it was always a developer error. Here is an example:

 

Let say you have following classes: Item, ItemStoragePlace, DocumentLineItem.

 

Primary key of Item: ITEMNO (char)

Primary key of ItemStoragePlace: ITEMNO (char) and STORAGEPLACENO (char)

Primary key of DocumentLineItem: OID (integer)

 

DocumentLineItem has a one to one relationship to Item (item):

join from: ITEMNO to: ITEM.ITEMNO

 

and ItemStoragePlace (itemStoragePlace):

join from: ITEMNO to: ITEMSTORAGEPLACE.ITEMNO

join from: STORAGEPLACENO to: ITEMSTORAGEPLACE.STORAGEPLACENO

 

Note: The same field ITEMNO is used in two relationships.

 

Lets assume we have following items with primary key ITEMNO: IT01, IT02

 

Item storage places with primary key ITEMNO, STORAGEPLACENO:

 

IT01, ST01

IT02, ST01

 

If you create a new DocumentLineItem and set item to IT01, set itemStoragePlace to IT02, ST01, you would get this error.

 

In our case, we were fortunately able to duplicate the problem in development image. So we were able to track down the issue.

 

This error in our case occurs if the same field is used in two different joins and if we provide Glorp different values for the same field.

 

Regards,

Madhu.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to glorp-group...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/0805be95-903b-46e3-bb5c-2659e4a36366%40googlegroups.com.

[jtuchel]

Hi Madhu,

thank you very much for this very appreciated hint. We'll have to investigate along these lines. This is an excellent starting point for further logging and/or testing in a dev image to get a glimpse of what is causing this.

What makes this thing so ugly is tha fact that the Exception itself does not give a slightest hint at anything. Nor what object is affected, nor which mapping is the one that's affected. I'd like to help in improving such things, but still am not good enough in fixing a lot of Glorp Code. Unfortunately, it seems that Cincom is not very interested in involving people from outside of the company. Or I am just very bad at getting in touch with people.

Does anybody know who I might talk to in order to address such things? I don't think that only the VAST port of Glorp is bad at throwing helpful exceptions, so I guess improvements could also help Cincom's customers and Glorp users on all platforms.

Joachim

To unsubscribe from this group and stop receiving emails from it, send an email to glorp...@googlegroups.com.