Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0011556
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformmajorhave not tried2009-11-30 15:442010-01-20 00:01
ReporterplujanView Statuspublic 
Assigned Tomtaal 
PriorityurgentResolutionno change requiredFixed in Version
StatusclosedFix in branchpiFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product Version2.50MP9SCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0011556: 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.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to defect 00118862.50MP10 closedmtaal When updating from mp8 to mp10 having spanish pack pro installed, I get an exception 

-  Notes
(0022261)
mtaal (manager)
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 (manager)
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.

- Issue History
Date Modified Username Field Change
2009-11-30 15:44 plujan New Issue
2009-11-30 15:44 plujan Assigned To => mtaal
2009-11-30 15:45 plujan Status new => acknowledged
2009-11-30 15:45 plujan Status acknowledged => scheduled
2009-11-30 15:45 plujan fix_in_branch => pi
2009-11-30 18:33 mtaal Note Added: 0022261
2010-01-19 20:29 mtaal Relationship added related to 0011886
2010-01-19 20:30 mtaal Note Added: 0023580
2010-01-19 20:30 mtaal Status scheduled => closed
2010-01-19 20:30 mtaal Duplicate ID 0 => 11886
2010-01-19 20:30 mtaal Resolution open => no change required
2010-01-20 00:01 anonymous sf_bug_id 0 => 2935286


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker