a8m
commented
3 years ago Hey @gedw99 and thanks for reaching out.
The underlying schemas specification is "generic" (language agnostic), and HCL was started as a first experiment for implementing it. We plan to provide also support for JSON, SQL, TypeScript, and a Go API for defining the schema as well. You can find more about it on atlas/schemaspec.
Normally a developer would create a migration script as they work. Alternatively, they can also diff two databases later to produce a migration script.
Both options will be supported in the upcoming releases. A way to move from the current database state to the desired state (defined in HCL for example), and a way to generate a migration spec/script.
I ask this because i am facing this issue many databases at the moment. The databases are NOT controlled by a DBA or DEV; but have new data schemas being developed at runtime by users, and so using HCL provides a way to determine the difference between the actual schema of the database and the intended one.
Also JSON Schema is used by the User to describe what they want the DB to model. These JSON Schema are then translated at runtime into DB Migration scripts. So i could then instead create a HCL script and then compare that against the actual DB, and then find the diff of what needs to be applied at runtime. Very useful.
We plan to provide more than this. Please, if you have time to discuss this, let me know how I can contact you. I'll be happy to share with you the project roadmap and get your feedback 😃
Please, feel free to ping me on ent's Slack channel or email.
gedw99
Quite curious about the potential uses cases with Atlas...
Is one of the reasons for the choice of HCL to do with being able to diff many HCL's and produce new one?
When HCL is used with Terraform, you need a central place for HCL that holds the existing state of the system.
Normally a developer would create a migration script as they work. Alternatively, they can also diff two datebase's later to produce a migration script.
I ask this because i am facing this issue many databases at the moment. The databases are NOT controlled by a DBA or DEV; but have new data schemas being developed at runtime by users, and so using HCL provides a way to determine the difference between the actual schema of the database and the intended one.
Also JSON Schema is used by the User to describe what they want the DB to model. These JSON Schema are then translated at runtime into DB Migration scripts. So i could then instead create a HCL script and then compare that against the actual DB, and then find the diff of what needs to be applied at runtime. Very useful.