Hi, jerreny, thanks your answer, REFERENCE BEGIN >>> Assuming your modules were independent, you could start with an empty database, run just the particular module's migration files on it, and then dump the schema of the result. But that's not the case. >>> REFERENCE END
As you said , that is the case, but not start with an empty database, any modules will use the same connect of database. When we install the CORE module, it will initailizes the database, the CORE module is depended by any modules. Assuming, my app has one core module and two module, the tree of directory structure as the following, /myapp /myapp/db /myapp/config.ru /myapp/readme.rdoc /myapp/Gemfile /myapp/public /... /myapp/modules /... /myapp/modules/core /myapp/modules/core/app /myapp/modules/core/views /myapp/modules/core/migrations /... /myapp/modules/blog /myapp/modules/blog/app /myapp/modules/blog/views /myapp/modules/blog/migrations /... /myapp/modules/forums /myapp/modules/forums/app /myapp/modules/forums/views /myapp/modules/forums/migrations /... /myapp/modules/wiki /myapp/modules/wiki/app /myapp/modules/wiki/views /myapp/modules/wiki/migrations /... /... other modules /... As you see, the migrations directory of CORE module stores the migration that created the USER table. And the migration of BLOG module will denpends the USER table, it also alters some columns of the USER table. (such as, add a ADDRESS field to USER table) Similarly, the FORUMS and others modules will depends the CORE module for the USER table. Now, we need to packup the BLOG module and commit to the module repository for someone using it again. We need packup any operations of migration of database to the installing package of module. So, we how to export the schema to a migration that has ever operated the database. Or anyelse we can do as the better way to packup the database operation. On Dec 12, 7:59 pm, Jeremy Evans <[email protected]> wrote: > On Dec 12, 7:05 pm, coolesting <[email protected]> wrote: > > > > > Well, good approach, but something i have mistook in the example > > above, so sorry for my question. > > > My app consist with many modules, every module will create many > > migrations, we need to packup the module with itself migrations, it > > dose mean the migrations will be independent without relation to other > > migrations forwards. > > > For example, we creates a module called BLOG that creates the > > migration version of 004 and 005, the two migration contains two > > tables(user table, post table) and alters column of the table(article > > table, it creates by migration version of 002, other module) . > > > So, we need to checkout the schema(or migration) of database for > > packing up the module BLOG, > > > Now if i do it as you said, it will checkout other tables that we not > > turly need in the migration schema. > > Reading your post, your "modules" are not independent, since they > contain migrations that modify tables created by other modules. > Assuming your modules were independent, you could start with an empty > database, run just the particular module's migration files on it, and > then dump the schema of the result. But that's not the case. > > Let me take a step back and ask what you are trying to accomplish. If > you have a module with two migration files, why do you want the > (incomplete/ambiguous) schema for the combination of those two files > (which can't even work if the module's migrations depend on other > modules' migrations)? Are you just looking to combine two or more > migration files into a single file? If so, why? > > From my current understanding of your description of the problem, > there is no solution, because you are asking for something that does > not exist (a database schema for the result of multiple migrations > that alter tables not created in previous migrations). That suggests > that either my understanding is incorrect or your design is confused. > Hopefully the former. This is probably just a communication issue, as > I'm guessing English is not your first language. If anyone has a > better idea about what the coolesting wants, please chime in. > > Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
