there should only be one migration dir. if bundles ship with migration scripts they should be included in a migration script in the main dir. solves all problems.
Lukas On 19.02.2011, at 10:40, Benjamin Eberlei <[email protected]> wrote: > Its not just remove the --bundle parameter. This way currently the Commands > have to implement no special logic for iteration and default to the Doctrine > Migrations commands almost 100%. > > The following problems start to pop up when you execute migrations from > several directories: > > 1. Timing, what directory has to be executed before another. > 2. How to "skip" certain bundles you don't want to migrate now. > 3. Migrate to Version XYZ does mean very different things in each migration > directory context. Its impossible to merge this. > 4. We still need one migration table per migration directory. > > The following advantages there are: > > 1. You cannot forget to apply migrations > > I agree that we have to remove --bundle. But it will be some work to figure > out the skip and timing issues. > > One solution would be to make the migrations bundle configurable and have the > user list all the migrations manually. However with several bundles this > would not allow to use the convenience functionality of pointing to a > directory because again the versions get mixed up and are incompatible to > each other. > > greetings, > Benjamin > > On Fri, 18 Feb 2011 19:23:40 +0100 > Lukas Kahwe Smith <[email protected]> wrote: > >> Hi, >> >> So right now all the migration commands require a --bundle option (which >> would indicate it should really be an argument, but I digress). However that >> option is fundamentally flawed since it doesn't really limit the migration >> scripts to a single Bundle. Well it sort of does, except for the diff >> command, which will actually scan all entities regardless of the Bundle it >> is defined in. I checked the doctrine migration configuration and didn't see >> anything to limit the entities that are being processed. Nor do I really >> think it makes sense. >> >> Sure if I am providing a 3rd party Bundle it might make sense to provide >> migration scripts, that users can then reference, but really for an >> application you need a single project level migration directory. Imagine for >> example migrating data from one Bundle to another. This wouldn't work if >> migrations would be managed separately. >> >> Therefore I would propose to remove the Bundle option. >> >> regards, >> Lukas Kahwe Smith >> [email protected] >> >> >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony developers" 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/symfony-devs?hl=en >> > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" 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/symfony-devs?hl=en -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" 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/symfony-devs?hl=en
