I think that schema in model is a very good idea. It can make
development much faster.
The model and the schema overlap in so many ways. I think it really
does make sense to try to bring them together so that I don’t have to
repeat myself so much.
At some level, whether its in migrations or in the DB schema, I have
to specify all the columns as well as their lengths and unique
constraints; why not do it all inside the model and have that set up
all the validates_* rules at the same time?
end
This is beautiful.
New validations for the title. We noticed that the summart should
really
be a :text, and not a :string. We changed that, but this didn’t
destroy
our data because we just convert the string field to a text field.
Why bother to specify :text vs. :string at all? When you use the
validate_length
method, and it exceeds 255 characters, the column type should change
from CHAR
to TEXT, eg:
attribute :summary, :string do |t|
t.validate_length :in => 1…100 # column is CHAR(100)
end
Is changed to:
attribute :summary, :string do |t|
t.validate_length :in => 1…999 # column is TEXT
end
–
Thanks,
Dan
Dan K. Email: [email protected]
Autopilot Marketing Inc. Phone: 1 (604) 820-0212
Web: http://www.autopilotmarketing.com
Sounds interesting… Please keep us posted! 
b
I am going to push ahead with rails because it seems to have the most
active development community. I’ve decided to try and solve the
inelegant Model - DBSchema duality that I’ve been struggling with by
using a MetaModel class that is edited using a ROR application. This
MetaModel class will keep track of its list of migration code that adds
and removes each model variable as well as all of the validation code
and other logic associated with each model variable and method. It will
all be presented as a unified whole to the developer consistent with
DRY, even if the implementation behind the scenes continues to use the
current fragmented approach. In this way, the MetaModel manages the
repetition inherent in the Model-DBSchema duality and the developer can
stay DRY.
When a Model class is needed, the MetaModel will assemble the parts from
the database and dynamically create the appropriate ActiveRecord code
which is then run through an eval statement. When a model is changed in
a way that affects the database, migration code is generated and run
behind the scenes. Controllers, views and routes will spring forth from
the database in a similar way. Since all parts will be timestamped,
versioning and rollback will come for free. Multiple ROR “applications”
could be managed at once though the same interface, sharing the same
components which are loaded as needed. Non web interface view code
(FOX, Tk) for these models could also be managed.
The only disadvantage I can see so far is that development will take
place though a web browser and not your editor of choice. But I’ve done
a similar thing years ago with a mod_perl system and it wasn’t too
painful. Anyone been down this road already with ROR?