I use migration from application level versioning. App starts and from a CNF file is informed if it is a new version. Compares with a previous existing database and starts the migration. If it is new run or a new database. It just creates the tables and views, which is the simple part and implementation. The bad part and most difficult one is when having to upgrade the db from a very old version. I always will have to change implementation code when the model changes. To pedantically map field names with what it is in the db.
@@NeutronDev Hello, it is currently in a web application, called LifeLog, where log entries and app settings are stored in several database flavours. The PerlCNF I wrote from scratch as a library aiding all this. Was today working on it.
📝Article: neutrondev.com/models-application-code-in-migrations-good-or-bad/
I use migration from application level versioning. App starts and from a CNF file is informed if it is a new version.
Compares with a previous existing database and starts the migration. If it is new run or a new database.
It just creates the tables and views, which is the simple part and implementation.
The bad part and most difficult one is when having to upgrade the db from a very old version.
I always will have to change implementation code when the model changes.
To pedantically map field names with what it is in the db.
🤔 interesting approach. What type of application is it? Thanks for sharing 💜
@@NeutronDev Hello, it is currently in a web application, called LifeLog,
where log entries and app settings are stored in several database flavours.
The PerlCNF I wrote from scratch as a library aiding all this. Was today working on it.