3 ms·
I have made a similar solution in-house. I kinda agree with the YAML nay-sayers. I settled on KDL instead as the description language (https://kdl.dev/ https://
by slooonz 2y ago
I have made a similar solution in-house. I kinda agree with the YAML nay-sayers. I settled on KDL instead as the description language (https://kdl.dev/ https://kdl.dev/) ; maybe give it a try ?
- slooonz 2y agoAlso, you should consider migrations to be the first-class citizen and entities to be derived on it. On our system, we have migration "create-users-table" { create-table "users" { column "id" "number" dbtype="increments" } } migration "add-user-last-device" { alter-table "users" { column "last_device" "string" } } This implicitly defines an "User" entity which has two fields, "id" and "lastDevice". But now we can also generate migrations (in our case, knex migrations). It’s harder and less reliable to go the other way, starting from current database schema + current description to migration.
- brunaxLorax 2y agoMigrations are a tricky point I agree. In your system, do you keep your original model files as they were at the beginning or do you change them too ?