Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011556Openbravo ERPA. Platformpublic2009-11-30 15:442010-01-20 00:01
Reporterplujan 
Assigned Tomtaal 
PriorityurgentSeveritymajorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOS5OS Version
Product Version2.50MP9 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0011556: ValidationException when updating from MP8 to MP9
DescriptionChecking the log of an update when updating from MP8 to MP9 I can see this:

     [java] Building runtime model
     [java] Model read in-memory, generating mapping...
     [java] org.openbravo.base.validation.ValidationException:
     [java] tADRecordrange: Property ADSystem.tADRecordrange only allows instances of java.lang.Long but the value is an instanceof java.lang.Float
     [java] org.openbravo.base.validation.ValidationException:
     [java] tADRecordrangeInfo: Property ADSystem.tADRecordrangeInfo only allows instances of java.lang.Long but the value is an instanceof java.lang.Float
     [java] org.openbravo.base.validation.ValidationException:
     [java] tADTransactionalrange: Property ADSystem.tADTransactionalrange only allows instances of java.lang.Long but the value is an instanceof java.lang.Float
     [java] Dal layer initialized
Steps To ReproduceOn an MP8, scan for updates and get MP9. Rebuild the system and once finished, check the logs. You will see above message.
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
related to defect 00118862.50MP10 closed mtaal When updating from mp8 to mp10 having spanish pack pro installed, I get an exception 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2009-11-30 15:44plujanNew Issue
2009-11-30 15:44plujanAssigned To => mtaal
2009-11-30 15:45plujanStatusnew => acknowledged
2009-11-30 15:45plujanStatusacknowledged => scheduled
2009-11-30 15:45plujanfix_in_branch => pi
2009-11-30 18:33mtaalNote Added: 0022261
2010-01-19 20:29mtaalRelationship addedrelated to 0011886
2010-01-19 20:30mtaalNote Added: 0023580
2010-01-19 20:30mtaalStatusscheduled => closed
2010-01-19 20:30mtaalDuplicate ID0 => 11886
2010-01-19 20:30mtaalResolutionopen => no change required
2010-01-20 00:01anonymoussf_bug_id0 => 2935286

Notes
(0022261)
mtaal   
2009-11-30 18:33   
This is caused by a change in ad_reference for an ad_column. Some generated entities still have the setDefaultValue calls in their constructor with the incorrect type (the previous ad_reference). The build does not fail because the validation exceptions are caught in the BaseOBObject.setDefaultValue and translated into an error log message.

As the build can continue it is not nice to log an error. The question is what would be a good approach:
1) log a warning
2) don't log anything

The pro of the first case is that in development you are aware of strange situations when a warning gets logged. The con is that the warning is also shown when upgrading and then it is not usefull.
So when upgrading or installing it makes sense to not log anything.

On the other hand it only happens rarely that the type of a column changes. So it is a very rare case that a warning will be logged.

gr. Martin
(0023580)
mtaal   
2010-01-19 20:30   
The solution for this issue:
https://issues.openbravo.com/view.php?id=11886 [^]
changes the way generate entities is done when updating the database. This means that this issue should not occur anymore anyway. Closing it therefore.