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.
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 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 [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/0805be95-903b-46e3-bb5c-2659e4a36366%40googlegroups.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. From: [hidden email] <[hidden email]> On Behalf Of 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: 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.
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 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 -- 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 [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/002001d62545%242965b1f0%247c3115d0%24%40gmail.com. |
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 Am Freitag, 8. Mai 2020 16:30:12 UTC+2 schrieb 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 [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/glorp-group/d3eb082d-8e30-42c5-a88e-0ae5500c142e%40googlegroups.com. |
Free forum by Nabble | Edit this page |