Project:
| View Revisions: Issue #41227 | [ All Revisions ] [ Back to Issue ] | ||
| Summary | 0041227: API Change: One-to-many cleanup (Functional team) | ||
| Revision | 2019-07-04 16:36 by vmromanos | ||
| Description | Due to the one-to-many cleanup project, many relationships between entities have been removed from the Java model classes generated by DAL. You can see details about the affected columns at https://docs.google.com/spreadsheets/d/1hdwjGM4_3TJ-9Bcylh_w_MM54_1T_cUlicaPfEyH1MQ [^] This is done by setting the AD_Column.is_child_property_in_parent to 'N' for the selected columns. This action creates an expected API change that widely affects many Openbravo 3 classes. More details: http://ci.openbravo.com/view/try/job/try-api/7262/consoleFull [^] The approach we have followed for the cleanup is: 1. to keep always any relationship already consumed by internal or external modules (any module published in the forge). 2. for the rest of the relationships, try to be aggressive and remove as many as possible, leaving only the relationships that clearly make sense from a Functional POV and that are safe from a Performance POV, ie which don't load too many objects in memory on a standard environment. Due to the above approach the API change risk could be classified as "high". However, in case of any external module not currently published in the forge is affected by this change, the developer can easily revert back to the previous API by running the following SQL and exporting the result to a template: update ad_column set is_child_property_in_parent = 'Y' where ad_column_id = '<AffectedColumnID>'; |
||
| Revision | 2019-07-04 10:18 by vmromanos | ||
| Description | Due to the one-to-many cleanup project, many relationships between entities have been removed from the Java model classes generated by DAL. You can see details about the affected columns at https://docs.google.com/spreadsheets/d/1hdwjGM4_3TJ-9Bcylh_w_MM54_1T_cUlicaPfEyH1MQ [^] This is done by setting the AD_Column.is_child_property_in_parent to 'N' for the selected columns. This action creates an expected API change that widely affects many Openbravo 3 classes. More details: http://ci.openbravo.com/view/try/job/try-api/7262/consoleFull [^] The approach we have followed for the cleanup is: 1. to keep always any relationship already consumed by internal or external modules (any module published in the forge). 2. for the rest of the relationships, try to be aggressive and remove as many as possible, leaving only the relationships that clearly make sense from a Functional POV and that are safe from a Performance POV, ie which don't load too many objects in memory on a standard environment. Due to the above approach the API change risk could be classified as "high". However, in case of any external module not currently published in the forge is affected by this change, the developer can easily revert back to the previous API by running the following SQL and exporting the result to a template: update ad_column set is_child_property_in_parent = 'N' where ad_column_id = '<AffectedColumnID>'; |
||
| Revision | 2019-07-04 10:09 by vmromanos | ||
| Description | Due to the one-to-many cleanup project, many relationships between entities have been removed from the Java model classes generated by DAL. You can see details about the affected columns at https://docs.google.com/spreadsheets/d/1hdwjGM4_3TJ-9Bcylh_w_MM54_1T_cUlicaPfEyH1MQ [^] This is done by setting the AD_Column.is_child_property_in_parent to 'N' for the selected columns. This action creates an expected API change that widely affects many Openbravo 3 classes. More details: http://ci.openbravo.com/view/try/job/try-api/7262/consoleFull [^] The approach we have followed for the cleanup is: 1. to keep always any relationship already consumed by internal or external modules (any module published in the forge). 2. for the rest of the relationships, try to be aggressive and remove as many as possible, leaving only the relationships that clearly make sense from a Functional POV and that are safe from a Performance POV, ie which don't load too many objects in memory on a standard environment. Due to the above approach the API change risk could be classified as "medium". However, in case of any external module not currently published in the forge is affected by this change, the developer can easily revert back to the previous API by running the following SQL and exporting the result to a template: update ad_column set is_child_property_in_parent = 'N' where ad_column_id = '<AffectedColumnID>'; |
||
| Revision | 2019-07-04 10:07 by vmromanos | ||
| Description | Due to the one-to-many cleanup project, many relationships between entities have been removed from the Java model classes generated by DAL. You can see details about the affected columns at https://docs.google.com/spreadsheets/d/1hdwjGM4_3TJ-9Bcylh_w_MM54_1T_cUlicaPfEyH1MQ [^] This is done by setting the AD_Column.is_child_property_in_parent to 'N' for the selected columns. This action creates an expected API change that widely affects many Openbravo 3 classes. More details: http://ci.openbravo.com/view/try/job/try-api/7262/consoleFull [^] The approach we have followed for the cleanup is: 1. to keep always any relationship already consumed by internal or external modules (any module published in the forge). 2. for the rest of the relationships, try to be aggressive and remove as many as possible, living only the relationships that clearly make sense from a Functional POV and that are safe from a Performance POV, ie which don't load to many objects in memory on a standard environment. Due to the above approach the API change risk could be classified as "medium". However, in case of any external module not currently published in the forge is affected by this change, the developer can easily revert back to the previous API by running the following SQL and exporting the result to a template: update ad_column set is_child_property_in_parent = 'N' where ad_column_id = '<AffectedColumnID>'; |
||
| Copyright © 2000 - 2009 MantisBT Group |
 |