...
- create stub files for event handler, tag processor, unit config
- automatically determine used labels and DB table name based on prefix (will also ensure that prefix is named according to coding guidelines)
- automatically put correct Fields array definition based on database (no need to manually use "System Tools" and copy paste from there)
- with the help of additional command options fine-tune unit to be generated, e.g.:
- add change tracking fields, e.g. CreatedOn, UpdatedOn
- connect to Priority Helper
- make sub-item of other unit (automatic setup of foreign key and stuff)
- you name it
Database migration creation
Right now we have central project_upgrades.sql file where all database migrations are being listed. Because all migrations are in single file a unique revision number must be supplied by developer. Although there is validation in place that there are no duplicate revisions from time to time developers manage to create duplicates. This is a problem because such revisions will be silently ignored and only in time developer will be able figure out that in past particular revision wasn't executed.
If we switch to file-per-revision system (see Incorporate "upgrades.sql" into "project_upgrades.sql" [5.2.1-RC1] and Changing way, who upgrade scripts are stored) then with help of command from below it will be possible to automatically create unique files for each database migration (including PHP support):
| No Format |
|---|
in-portal migration:create "#task-number - Task Description" |
Possibilities are limit-less.
...