a.) where is this main migration dir b.) how to include the shipped migrations
On Sat, 19 Feb 2011 14:06:48 +0100, Lukas Kahwe Smith <[email protected]> wrote: > 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
