Rails - Aug 2006 - Organizing the db/migrate folder

Hiall,

I was wondering how you guys are organizing your migrations files under
db/migrate? I have like 60 database tables initially, and if I exercise
migrations the way they should be exercised, I guess this will become even
more files ... Now maybe you say 70 files ain''t that much anyway :) but
the
thing of course is that these files logically belong to different areas of
my application (domain), that''s why I really would like to group them
in
folders for easier navigation and making the structure explicit. I read
about how rails doesn''t care about putting controllers and models in
subfolders, tried that out and it worked, although what I really like to do
in the end is properly scope these things with modules. However, migrations
don''t seem to get recognized in subfolders of db/migrate.

Does anyone know of a solution? Or do I really need to have 60+ oftentimes
logically unrelated files under one folder?

Thx in advance!

Martin Gamsjaeger
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060817/6c6a4be9/attachment.html

> 
> I was wondering how you guys are organizing your migrations files under
> db/migrate?
switched off of SQL a few months ago. not looking back :)
> more files ... Now maybe you say 70 files ain''t that much anyway
:) but the
> thing of course is that these files logically belong to different areas of
> my application (domain), that''s why I really would like to group
them in
> folders for easier navigation and making the structure explicit. I read
> don''t seem to get recognized in subfolders of db/migrate.
> 
> Does anyone know of a solution? Or do I really need to have 60+ oftentimes
> logically unrelated files under one folder?
migrations are bound to a specific numeric order. putting them in folders would
mean theyd still need to be numbered, so you want
forms/04_steak_dinner_registrants.rb and venues/05_dining_rooms.rb ?

i would consider exposing your schema via resolvable URIs which return schema
description, this is the foundation of the semantic web. then you can do as many
sub''folders'' as you want..

i think the problem youre describing is the dichotomy of migrations versus model
code. maybe you want dr nic''s magic models, or the inverse of that, or
an RDF store. the current way is definitely suboptimal, but porably the most
pragmatic, in terms of levering existing practices, and avoiding black-magic
which is likely to fail