Need help debugging "Inconsisten Values in field"
Locked
 
|
I have a problem popping up in production much more often than I'd like. Unfortunately, I cannot reproduce it in any of our test environments. Users told me what they are doing, and I tried the same dozens and hundreds of times, but I don't understand what is going on. When users commit a Transaction after some operation, they sometimes get an "Inconsistent values in field" error. Sometimes they also get a "Conflicting Values in Rows", which seems to be somewhat the same thing...?). A few things are strange here. But let's first look at a part of the walkback: DirectMapping>>#mapFromObject:toTarget:puttingRowsIn: receiver = a DirectMapping(id)
arg1 = a Konto (1572965): 1791 Umsatzsteuer frühere Jahre arg2 = a Konto (1572965): 1791 Umsatzsteuer frühere Jahre arg3 = a RowMapForMementos temp1 = 1572965 temp2 = 1572965 temp3 = a DatabaseRow(KPELEMENT) Field(KPELEMENT.id)->1572848 Field(KPELEMENT.version)->an Object
Field(KPELEMENT.typ)->'KO'
Field(KPELEMENT.bezeichnung)->an Object
Field(KPELEMENT.kontonummer)->an Object
Field(KPELEMENT.anfangssaldo)->an Object
Field(KPELEMENT.abschlusssaldo)->an Object
Field(KPELEMENT.euerKz)->an Object
Field(KPELEMENT.cont_id)->an Object
Field(KPELEMENT.rahmen_element_id)->an Object
Field(KPELEMENT.wurzel_id)->an Object
Field(KPELEMENT.metakonto_nr)->an Object
Field(KPELEMENT.kto_orig_id)->an Object So first thing here is: it seems most contents of the Row are "an Object" which definitely is rubbish. But reading the code of this method and looking at the temps and args, I have at least some idea of what might be going wrong here. This is the method: mapFromObject: anObject toTarget: target puttingRowsIn: aRowMap | dbValue value row | self canWrite ifFalse: [^self]. value := self getValueFrom: anObject. value := self session realObjectFor: value ifNone: [^self]. dbValue := self convertedDbValueOf: value. row := aRowMap findOrAddRowForTable: self field table withKey: target. row at: field put: dbValue What I find interesting is that the row which is displayed here is not the one that the meapper was looking for. The row to be changed has the id 157296, but the row in the Walkback has the id Field(KPELEMENT.id)->157284. So I guess the problem is that #findOrAddRowForTable: self field table withKey: target. returns the wrong row... There is no point in changing the contents of ID anyways, since it is the primary key of the row.... So what would a Glorp pro do to "debug" this deeper - especially given that we have no way to reproduce this problem (yet)? Joachim You received this message because you are subscribed to the Google Groups "VA Smalltalk" 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/va-smalltalk/d516418a-310d-41b6-b7b8-b30c8359d7d4n%40googlegroups.com. |
Re: Need help debugging "Inconsisten Values in field"
|
|
Joachim,
Trying to fix an error that you cannot reproduce during execution is one of the hardest things since you have to run the code in your mind to make it happen :-) What I'd like to assess first, just to help you think about it, is what is the structure of the table. Did you redefine any #= and/or #hash method? Did you find any test involving directly #findOrAddRowForTable:withKey: ? I'd start there. Regards! Esteban A. Maringolo On Thu, Oct 22, 2020 at 10:31 AM Joachim Tuchel <[hidden email]> wrote: > > > I have a problem popping up in production much more often than I'd like. Unfortunately, I cannot reproduce it in any of our test environments. Users told me what they are doing, and I tried the same dozens and hundreds of times, but I don't understand what is going on. > > When users commit a Transaction after some operation, they sometimes get an "Inconsistent values in field" error. Sometimes they also get a "Conflicting Values in Rows", which seems to be somewhat the same thing...?). > > A few things are strange here. But let's first look at a part of the walkback: > > DirectMapping>>#mapFromObject:toTarget:puttingRowsIn: > receiver = a DirectMapping(id) arg1 = a Konto (1572965): 1791 Umsatzsteuer frühere Jahre > arg2 = a Konto (1572965): 1791 Umsatzsteuer frühere Jahre > arg3 = a RowMapForMementos > temp1 = 1572965 > temp2 = 1572965 > temp3 = a DatabaseRow(KPELEMENT) > Field(KPELEMENT.id)->1572848 > Field(KPELEMENT.version)->an Object Field(KPELEMENT.typ)->'KO' Field(KPELEMENT.bezeichnung)->an Object Field(KPELEMENT.kontonummer)->an Object Field(KPELEMENT.anfangssaldo)->an Object Field(KPELEMENT.abschlusssaldo)->an Object Field(KPELEMENT.euerKz)->an Object Field(KPELEMENT.cont_id)->an Object Field(KPELEMENT.rahmen_element_id)->an Object Field(KPELEMENT.wurzel_id)->an Object Field(KPELEMENT.metakonto_nr)->an Object Field(KPELEMENT.kto_orig_id)->an Object > > So first thing here is: it seems most contents of the Row are "an Object" which definitely is rubbish. > But reading the code of this method and looking at the temps and args, I have at least some idea of what might be going wrong here. This is the method: > > mapFromObject: anObject toTarget: target puttingRowsIn: aRowMap > > | dbValue value row | > > self canWrite ifFalse: [^self]. > value := self getValueFrom: anObject. > value := self session realObjectFor: value ifNone: [^self]. > dbValue := self convertedDbValueOf: value. > row := aRowMap findOrAddRowForTable: self field table withKey: target. > row at: field put: dbValue > > What I find interesting is that the row which is displayed here is not the one that the meapper was looking for. The row to be changed has the id 157296, but the row in the Walkback has the id Field(KPELEMENT.id)->157284. So I guess the problem is that #findOrAddRowForTable: self field table withKey: target. returns the wrong row... > > There is no point in changing the contents of ID anyways, since it is the primary key of the row.... > > So what would a Glorp pro do to "debug" this deeper - especially given that we have no way to reproduce this problem (yet)? > > > Joachim > > > > > > -- > You received this message because you are subscribed to the Google Groups "VA Smalltalk" 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/va-smalltalk/d516418a-310d-41b6-b7b8-b30c8359d7d4n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "VA Smalltalk" 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/va-smalltalk/CAJMgPC%2Bd2y%3DSLFXW%2BxnqvmtgLe4q2w8c0AoSZXSJQUOQZN4Zwg%40mail.gmail.com. |
Re: Need help debugging "Inconsisten Values in field"
|
|
Hi Joachim, I don't know what could be the root of the problem, but since I know you are using Seaside and XD packaging, maybe using the binary stack dumper is a good idea. It should be fairly simple to use it in your case and you could potentially have way more information than on a walkback. Best, On Thu, Oct 22, 2020 at 10:52 AM Esteban Maringolo <[hidden email]> wrote: Joachim, Mariano Martinez Peck Software Engineer, Instantiations Inc. Email: [hidden email] Twitter: https://twitter.com/MartinezPeck Blog: https://marianopeck.wordpress.com/You received this message because you are subscribed to the Google Groups "VA Smalltalk" 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/va-smalltalk/CAOUkibHeuPcMSTF-oz3-DOrtjLVbXN5HYWjkLvZTHDPgEX%2BckA%40mail.gmail.com. |
|
|
Mariano, thanks fro the idea. I wonder why I didn't think of it. I guess it won't hurt at all if I can have a look at what was actually in the Caches and what objects were about to be saved in that Transaction... OTOH: there are a few open questions before I go and repackage for production... We use a few extensions in our app to write a new walkback file for each error. I am not proud of it, but we get up to a few dozen errors on busy days, so it s important to be able to find a certain walkback easily. Also, we send some walkbacks home by mail. I wonder in how far another dumping policy might interfere with these extensions. Will we still get these walkbacks written to disk? Also, I wonder if our runtime will write a new stack dump on each error or if it will replace the same file every time an error occurs. And if so, how could we override this? As a side note: the documentation of teh remote debugging feature could use a little love. The terminology of all this dumping and remote debugging is a bit CICS heavy and leaves a few questions unanswered. Like "is the stack dump also part of remote debugging?" Luckily, there also is a little bit about it in the Seaside Traffic Lights demo packaging chapter, so I think I understand all I actually have to do is change the dumper policy (apart from the questions mentioned above). Joachim [hidden email] schrieb am Donnerstag, 22. Oktober 2020 um 17:41:43 UTC+2:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" 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/va-smalltalk/7a07217f-fe6f-46ee-acf8-6665d9eb1ec8n%40googlegroups.com. |
|
|
In reply to this post by Esteban A. Maringolo
Esteban, [hidden email] schrieb am Donnerstag, 22. Oktober 2020 um 15:52:51 UTC+2: Joachim, This is quite hard to do, I can tell from experience. Because, in theory (resp. my mind), my code is always perfect ;-) Joking aside, it is quite hard to understand what might be wrong here because we never saw this happen in a dev image. What I'd like to assess first, just to help you think about it, is Thanks for the idea. A stupid override of #= or #hash could be responsible for strange cache lookup results. I never touch #hash in general, but I wouldn't guarantee there is no override of #= in my business classes. So I checked and the only message close to that I have overridden is #<. To be really sure, I just went through the list of implementors of #= and #hash.
Yes, there are some. All of them green of course, But I'll dive into them now to understand a little better what might be going on... Thanks for your ideas! Joachim
You received this message because you are subscribed to the Google Groups "VA Smalltalk" 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/va-smalltalk/01b1e650-52b5-4f5b-91bf-02883eb9ad9bn%40googlegroups.com. |
«
Return to Instantiations
|
1 view|%1 views
| Free forum by Nabble | Edit this page |