3 ms·

Wait, so the author says we should design our own schema definition DSL, write some JSON that uses that DSL to define a database schema, and implement whatever

by AndrewO 17y ago

Wait, so the author says we should design our own schema definition DSL, write some JSON that uses that DSL to define a database schema, and implement whatever transformations are required to generate a working migration from that DSL? How is that lazy?

chasingsparks 17y ago
The author (me) is being lazy by not writing this. I am outsourcing (hopefully) the implementation of an idea. Also, the transformation into a db schema is only one alleged benefit. E.G. class User < ActiveRecord::Base json_def 'user_model.json' end display_form(@obj) etc
- AndrewO 17y ago
  I hope you take this as constructive criticism (and not me just being a jerk :), but I see a couple of problems: 1) JSON gives no benefit over a Ruby DSL (like ActiveRecord migrations). Is the schema file going to be consumed by client programs written in other languages? (Even so, in that case, you should probably just define ActiveRecord::Base.to_json_schema). Two languages are unnecessary when one will suffice. 2) When you start to define the schema in code[ft. 1], rather than in the database itself, you're leaving the Active Record pattern (as defined in PoEAA) and should probably look at other patterns (and the libraries that implement them). Data Mapper/DataMapper would probably be a good fit here. Also, you're loosing the benefits that migrations give of dealing with changes to the schema over time non-destructively. Dr Nic's Sexy Migrations did something that would diff a single schema file with the existing DB schema, but this is not the default solution. 3) Automatically generating forms from a model has tempted many Rails developers over the years. A rudimentary method would be possible using the existing reflection data (i.e. no need for a JSON schema DSL) and some added metadata. Google "rails admin ui" for some examples. However, "metadata" can easily turn into "writing forms in the model instead of the view" (I've seen it happen). That's why I'd avoid this. Also any forms more advanced than a simple create/edit interface and you're probably going to end up writing a partial anyway, especially if you need to add markup for formatting (e.g. how do you control if the generated form vertically or horizontally oriented? Meant to go in a table with others or independent?). ft. 1: Rails' Migrations are a special case. They should be a seen as a separate system from the ORM that was created later on to manage the complexity of changing schema. ActiveRecord classes still define their fields based on reflection from the database.

by AndrewO 17y ago

chasingsparks 17y ago

The author (me) is being lazy by not writing this. I am outsourcing (hopefully) the implementation of an idea. Also, the transformation into a db schema is only one alleged benefit. E.G. class User < ActiveRecord::Base json_def 'user_model.json' end display_form(@obj) etc

AndrewO 17y ago
I hope you take this as constructive criticism (and not me just being a jerk :), but I see a couple of problems: 1) JSON gives no benefit over a Ruby DSL (like ActiveRecord migrations). Is the schema file going to be consumed by client programs written in other languages? (Even so, in that case, you should probably just define ActiveRecord::Base.to_json_schema). Two languages are unnecessary when one will suffice. 2) When you start to define the schema in code[ft. 1], rather than in the database itself, you're leaving the Active Record pattern (as defined in PoEAA) and should probably look at other patterns (and the libraries that implement them). Data Mapper/DataMapper would probably be a good fit here. Also, you're loosing the benefits that migrations give of dealing with changes to the schema over time non-destructively. Dr Nic's Sexy Migrations did something that would diff a single schema file with the existing DB schema, but this is not the default solution. 3) Automatically generating forms from a model has tempted many Rails developers over the years. A rudimentary method would be possible using the existing reflection data (i.e. no need for a JSON schema DSL) and some added metadata. Google "rails admin ui" for some examples. However, "metadata" can easily turn into "writing forms in the model instead of the view" (I've seen it happen). That's why I'd avoid this. Also any forms more advanced than a simple create/edit interface and you're probably going to end up writing a partial anyway, especially if you need to add markup for formatting (e.g. how do you control if the generated form vertically or horizontally oriented? Meant to go in a table with others or independent?). ft. 1: Rails' Migrations are a special case. They should be a seen as a separate system from the ORM that was created later on to manage the complexity of changing schema. ActiveRecord classes still define their fields based on reflection from the database.