Improvements on Adempiere Data Dictionary
- 1 Improvements on Adempiere Data Dictionary
- 2 Benefits
- 3 Suggestions
- 3.1 1. Extend the concept of element to be abstract data type
- 3.2 2. The element should include a reference field to link to a reference
- 3.3 3. References should include validations
- 3.4 4. An element could be based on another element
- 3.5 5. New column in a table could be made up JUST by selecting a System Element (abstract data type)
- 3.6 6. Propagation of changes
- 3.7 7. Addition of new visual properties
Improvements on Adempiere Data Dictionary
- Initialy proposed by: Emilio Arrufat
- sf.net forum post
Some ideas to improve the data dictionary of Adempiere.
Adempiere concepts of element, reference, and column could be merged in order to simplify and accelerate development.
I am seeking for the concept of Data Dictionary as a collection of Abstract Data Types from which all the attributes of the objects of the system are composed. Those Abstract Data Types model and drive the aplication, its user interface and the BD schema. Abstracting the fact that data are stored in relational tables you could think of ADT as the domain the properties of persistent clases belong to.
Those definitions should encomprise display properties (how the data is presented to the user, such as label, alignement, ...), how they are stored (base type, length, precision), and to one extent how they form relationships (where used, BpartnerId relates inmediatly to a Bpartner instance)
They should form a hierarchy of data types. Ex:
Float<-Money<-PriceCur<-SalesPriceCur <-PurchPriceCur <-PriceBase<-SalesPriceBase <-PurchPriceBase
All those data types are based on Money, which in turn is a base type of Float (which is to be the database field type). For SalesPriceCur most of the properties are those of Money, but surely the Label property is to be overloaded, as it could be the NumberOfDecimalsShown property.
A. Centralized definition
Ex.: the SalesPriceCur is defined only once.
B. Ease of modification
Should the price change, in say, label or number of decimals, change it in one place and let the system propagate the changes.
C. Less errors
How many times have we defined two columns for the same data, Say SalesPriceCur, but with different precision?
D. Possibility for changing id values
Should it be possible to change the value for an id, say BpartnerId? Yes, if we can keep a record of all the columns that hold that data; how? All columns metada should be based on the same data type.
E. Could be the basis of a true object-oriented data manipulation language
I mean, by now Adempiere is tied to SQL and the basic types of fields in tables. May be someday the comunity could enhance the language to say:
PrintedCopies copies = Bpartner.getInvoicePrintedCopies()
Int copies = Bpartner.getInvoicePrintedCopies
This is an example not extracted from actual code
But concentrating on just Adempiere DD, I think it is not so far. In my opinion those properties for a data type are spread between Element, Reference and Column. I suggest to overload the Element with all the needed to become the Abstract Data Type.
- Developed. Detailed description and example:
This is what I think could be done with the minimum impact:
1. Extend the concept of element to be abstract data type
A element should include properties now found on table columns such as length, values, reference key, dynamic validation, name, not encrypted, reference and so on: all those that we could think as being common to more that one column.
3. References should include validations
Thus Element, Reference and Validation form a the Element unit.
4. An element could be based on another element
An element could be based on another element, inheriting all the propoperties of its ancestor and being allowed to change only some of them, those related to user interface. When selecting its ancestor almost all of its proper should be filled with those of the ancestor.
5. New column in a table could be made up JUST by selecting a System Element (abstract data type)
To minimize the impact on Adempiere I would suggest filling-up all the current properties of table column with those in the selected element ans its reference, but keeping some of them not updatable (those related to storage). We must think if the others (references, validations,..) should be let updatable.
6. Propagation of changes
Since there is already the "Where used element" list, a change in property of an element could update the columns property. If the change needs to update database schema it would be possible to list over those columns and sync each in turn. That it turn will affect all the windows and reports.
7. Addition of new visual properties
Addition of new visual properties such as alignment and so on, seem to me more feasible to be done for the whole system (render Window -->render column --> element -->value of alignment)