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 G.
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
but