iDempiere data dictionary update

[Vadim Scherbakov]

I'am newbie in iDempiere and going to apply my Java expirience to application domain close to my main activities (accouning systems). I have some questions about iDempiere architecture

1. Why not used table objects to keep functional not related to business domain (storage layer, security and so on)

2. If table objects not used, why changes to schema released by sql scripts (individial for each RDMS), instead of using data dictonary. Moreover, repository has db\ddlutils folder, that contant something like data dictionary, but this data int used to make changes to schema. It seems to be generated from database.

[Chien tony]

You shoud user databse in folder  ../idempiere/org.adempiere.server-feature/data/seed

Vào 02:43:01 UTC+7 Thứ Hai, ngày 17 tháng 8 năm 2015, Vadim Scherbakov đã viết:

[Vadim Scherbakov]

You tell about initial database backup. I opposite said about process of update database schema by many developers. Please, carefully read my initial message.

[xolali]

Hi,

Review the following:

http://www.adempiere.com/Application_Dictionary_Layers

http://www.adempiere.com/Application_Dictionary

It will help you understand the architecture better. 

Basically Table and column is the OR mapper between idempiere business objects (MClasses) and the database tables. Data Access layer code is handled by the X_Classes which are generated and not to be modified and extend the critical PO class which is the corner stone of the entire system. Business logic is in MClass and these extend the X_Classes.

Scripts are needed to migrate dictionary changes from one installation to another to prevent manual work and also centralized ID is used to make sure there are no primary ID clashes when your changes are to be installed by another person or moved into the core.

Xolali

[Vadim Scherbakov]

1. Application Dictionary must by file or group of files on disk (for example XML) that used for create database schema. Is that fil(e/es) exists for iDempiere?

2. With Application Dictionary update script can be generated automatially by compare old and new application dictionary. This means that old Application Dictionary must be stored in database.

3. ID clushing can be determined on the stage of generating new version of database schema. If that exist, recent Application Dictionary update are incorrent and must be reverted.