6
edits
Language and development rules: Difference between revisions
Jump to navigation
Jump to search
In English, the meaning of "eventually" is more like "at the end". This is different to German (and probably French), where the meaning of "eventuell" is more like "maybe".
Tag: 2017 source edit |
Dolichicken (talk | contribs) (In English, the meaning of "eventually" is more like "at the end". This is different to German (and probably French), where the meaning of "eventuell" is more like "maybe".) |
||
| Line 207: | Line 207: | ||
- import_key varchar(32) that will contain the import code YYYYMMDDHHMMSS if you make mass import | - import_key varchar(32) that will contain the import code YYYYMMDDHHMMSS if you make mass import | ||
- status smallint to store a status | - status smallint to store a status | ||
Optional | |||
- fk_user_creat or fk_user_author integer that is the id of user making creation | - fk_user_creat or fk_user_author integer that is the id of user making creation | ||
- fk_user_modif integer that is the id of user making change | - fk_user_modif integer that is the id of user making change | ||
| Line 319: | Line 319: | ||
*No DELETE CASCADE and ON UPDATE CASCADE | *No DELETE CASCADE and ON UPDATE CASCADE | ||
Such SQL instructions are forbidden because they bypass the business rules of the application. For example, if there is a delete cascade between table A and B, when the application will execute the code to remove a record in A, the children into table B will also be removed. If there was a Dolibarr PHP trigger (for example bring by an external module) on the deletion of record of B (for example to validate the deletion or to execute a complementary action), the DELETE CASCADE will be executed without having the Dolibarr PHP trigger executed, missing the validation or actions of the PHP trigger of the module. So all business rules must be implemented on the same side (the server PHP side), this is the reason why business rules implemented on Database are not allowed (same situation than the next point on Database triggers) | Such SQL instructions are forbidden because they bypass the business rules of the application. For example, if there is a delete cascade between table A and B, when the application will execute the code to remove a record in A, the children into table B will also be removed. If there was a Dolibarr PHP trigger (for example bring by an external module) on the deletion of record of B (for example to validate the deletion or to execute a complementary action), the DELETE CASCADE will be executed without having the Dolibarr PHP trigger executed, missing the validation or actions of the PHP trigger of the module. So all business rules must be implemented on the same side (the server PHP side), this is the reason why business rules implemented on Database are not allowed (same situation than the next point on Database triggers) | ||