JSON as a Universal DB Model DSL
pathdependent.com
pathdependent.com
Moreover the problem with database schemas has never been to represent them or reflect on them, but to migrate between them.
See http://www.post-facto.org/ for an interesting approach (presentation by the author: http://hosting3.epresence.tv/fosslc/1/watch/128.aspx).
column name | generalized type | validation rule | hidden?
------------------------------------------------------------------
first_name | text | name_regex | false
last_name | text | name_regex | false
middle_name | text | name_regex | false
birth_date | date | over_18 | false
location | [double,double] | undefined | true
addresses | | has_many | false
(my point is that data format doesn't matter - JSON, YAML, XML, |'s and -'s are just different "colors" giving semantic meaning to your data: but it's what you can do with that data which is important)
How is that lazy?
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)
etc1) 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.