Knetic
commented
8 years ago Some limitations:
- Arrays have no definite analogue in SQL. For a first-pass, it makes sense to ignore them.
- Table creation order will matter. #20 has been made to address that.
- Tables should be assumed to exist, and that data should not be dropped. Therefore, every table definition should act like an "upsert" of the table definition. (for reference, http://stackoverflow.com/questions/16837134/alter-table-if-exists-or-create-if-doesnt)
- Field sizes will need to be unoptimal at first. Numbers/integers should take 4 bytes, strings should all be
nvarchar, with min/max length as specified by the constraints. If constraints for length are missing, assume 1024 length. In the future, it may be worth sketching an extension to json schema which allows clear sizing of strings, or perhaps by mixing an "rc" file of some sort into the schema generation process, which clarifies string sizes. - Booleans will need to be represented by a bit field, 0 = true, 1 = false.
- Regex constraints are not possible, and should be ignored.
- "module" as specified should refer to the database the tables will live in.
Given that the schemas can be accurately represented by RDMS, presilo ought to be able to generate SQL queries which can construct tables to match schemas.
This is for mysql specifically, since MSSQL will have slightly different syntax for constraints.