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

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0009757
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] Z. Othersmajorhave not tried2009-07-03 11:152009-07-22 00:00
ReportershuehnerView Statuspublic 
Assigned Toharikrishnan 
PriorityimmediateResolutionfixedFixed in Version
StatusclosedFix in branchFixed in SCM revisione2aa45438b62
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionpiSCM revision 
Merge Request Status
Review Assigned To
OBNetwork customerNo
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0009757: API change:api check: build 62 fails

DescriptionThe following API check build failed:

http://builds.openbravo.com/job/erp_devel_pi-module-integrity-test/62/console [^]


+++++++++++++++++++++++++++++++++++++++++++++++++++
  Errors in API model validation
+++++++++++++++++++++++++++++++++++++++++++++++++++
  Column type change from date to NVARCHAR
  Column size decreased from 10 to 7: column: MA_INCIDENCE.STRTIME


Test did not validate API


java test:
Errors:

org.openbravo.model.manufacturing.transaction:
Bad
method org.openbravo.model.manufacturing.transaction.Incidence.getStartingTime(): type java.lang.String in api-checks/java/reference/250, but type java.sql.Timestamp in /var/www/localhost/htdocs/japi/62
Missing
method org.openbravo.model.manufacturing.transaction.Incidence.setStartingTime(java.lang.String): missing in /var/www/localhost/htdocs/japi/62
Proposed SolutionPlease add explanation why this change is needed and cannot be done without an API change and reassign issue to pjuvara.
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
related to defect 0007111 closeddmiguelez On Work Incidence, Starting Time field has no Time format 

-  Notes
(0017776)
shuehner (administrator)
2009-07-03 11:16

 The two errors, are coming from the same source. The change of a single column datatype.
(0017784)
shuehner (administrator)
2009-07-03 12:04

 @pjuvara:
If we allow this change we need extra effort to make a change in dbsourcemanager.

Right now this change does break update.database and (most likely) the content of the affected table is lost.
(0017787)
harikrishnan (viewer)
2009-07-03 12:41

 Since this field deals with the time we cant keep it as character in the database.Hence i made the change to timestamp.PJurvara whether we have to change in the API?.Hence im reassigning this issue to pjuvara.
(0017788)
harikrishnan (viewer)
2009-07-03 12:45

 Reference issue is https://issues.openbravo.com/view.php?id=7111 [^]
(0017901)
pjuvara (viewer)
2009-07-03 19:21

 I cannot accept this change for many reasons and it needs to be backed out and corrected.

Looking at the fix for issue 7111 it looks like in order to add proper UI level formatting, we changed the data type of the column. This is not needed in the first place.

Second, it looks like we change the type from DATE to NVARCHAR. DATE is a more appropriate data type to store date and time.

The correct fix for issue 7111 was to simply change the reference of the field to be time, without the need to change the data storage.

Last but not least, issue 7111 is low priority. We should never break a public API to fix a low priority issue.

In this case the correct course of action is to:
a) Re-open issue 7111
b) Backout the incorrect fix
c) Fix 7111 in the correct way
(0017903)
shuehner (administrator)
2009-07-03 19:24

 @pjuvara: The type was changed from NVARCHAR -> date. The output of the model test is incorrect and has the two relevant fields swapped (i created issue 9765 to track/fix this problem)
(0017904)
pjuvara (viewer)
2009-07-03 19:30

 After the comment by shuehner, I now understand that the fix was technically correct.
Yet, I believe it is not appropriate to break a public API in order to fix a minor issue that was not reported by a customer (7111 was reported internally by QA).

So I confirm my decision to reject this exception and I request the fix to be backed out.

Harikrishnan should investigate an alternative fix for 7111 that does not involve breaking the API. If that is not possible, we should postpone the fix for 7111 to after we have created the maintenance repository for 2.50 so that we can fix the issue for the next release without breaking the existing API.
(0018114)
rafaroda (viewer)
2009-07-10 16:20

 API change reverted https://issues.openbravo.com/view.php?id=7111#bugnotes [^]

- Issue History
Date Modified Username Field Change
2009-07-03 11:15 shuehner New Issue
2009-07-03 11:15 shuehner Assigned To => harikrishnan
2009-07-03 11:15 shuehner OBNetwork customer => No
2009-07-03 11:15 shuehner Relationship added related to 0007111
2009-07-03 11:16 shuehner Note Added: 0017776
2009-07-03 12:04 shuehner Note Added: 0017784
2009-07-03 12:41 harikrishnan Note Added: 0017787
2009-07-03 12:41 harikrishnan Assigned To harikrishnan => pjuvara
2009-07-03 12:45 harikrishnan Note Added: 0017788
2009-07-03 19:21 pjuvara Note Added: 0017901
2009-07-03 19:21 pjuvara Status new => scheduled
2009-07-03 19:21 pjuvara Assigned To pjuvara => harikrishnan
2009-07-03 19:21 pjuvara fix_in_branch => pi
2009-07-03 19:24 shuehner Note Added: 0017903
2009-07-03 19:30 pjuvara Note Added: 0017904
2009-07-06 09:30 rafaroda Issue Monitored: rafaroda
2009-07-10 16:20 rafaroda Note Added: 0018114
2009-07-10 16:20 rafaroda Status scheduled => resolved
2009-07-10 16:20 rafaroda Resolution open => fixed
2009-07-10 16:20 rafaroda Fixed in SCM revision => https://code.openbravo.com/erp/devel/pi/rev/e2aa45438b62f2f32aca9eac409e6f8a7b2700bb [^]
2009-07-10 16:20 rafaroda fix_in_branch pi =>
2009-07-21 11:09 plujan Status resolved => closed
2009-07-22 00:00 anonymous sf_bug_id 0 => 2825055

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker