[Flow] Flow: mysterious migration commands

[Jan Greth]

Hey, David, Beat & Christian!

Thanks for all of your replys. I think i got it now.
So, just to be sure:

1. I kickstart my Package, after that i do once (!) doctrine:update.
2. Now i edit my model etc and when i think i'm done with it, i fire 
doctrine:migrationgenerate.
3. In [FlowFolder]/Data/DoctrineMigrations/ i find my Migrationfiles - 
check them for needed datamigration etc and after that move them to 
[MY.Package]/Migration/Mysql/
4. Now i call doctrine:migrate and everything is fine.
5. Further in development restart at step 2.

Is that correct?

Also Christian mentioned TYPO3.Surf in his reply. I found the docs [1] 
but didn't "get warm" with it.
Do you have some other ressources (Blogposts, Forum Threds, Talk Videos, 
etc... ) about TYPO3.Surf which you can recommend ?
Or the best a small described example to dive in...

Thanks for your patience,
Jan

[1]: http://docs.typo3.org/surf/TYPO3SurfDocumentation/


Am 12.05.2015 um 08:42 schrieb Christian Loock:
> One important thing to add here:
>
> In migration scripts, you can add data migration aswell, like copying
> data from one field to another. In a lot of cases, doctrine:update would
> simple make you lose this data, since it only would take care of
> changing the DBs structure, but not migrate the data. This is important
> when you update you application and changes to your db structure have
> happened.
>
> So in short:
>
> Use doctrine:update only during development and once you want to deploy
> to a production environment, make sure to have working migrations. If
> you deploy using SURF, migration will be executed aswell. Pretty handy
> stuff :)
>
>
> Am 12.05.2015 um 08:30 schrieb Beat Guggisberg:
>> Hi
>>
>> I use the migration:update command only on my development machine
>> while im doing stuff to my models. After i finished a
>> feature/bugfix/whatever, i clear the database und create it new with
>> doctrine:migrate. Now i have a clean database to create the new
>> migration file. The file created is then corrected and split up to my
>> packages. now i can again use doctrine:migrate to get to the correct
>> database version. Now i test all the things again to make sure that
>> migration is correct.
>>
>> On the productive database you should never use doctrine:update
>> because it makes changes that can corrupt a future migration. Every
>> migration has to have the correct database-structure to be able to run
>> and change it to the next version. If a table or sometimes just a
>> field have been changed, then it will only quit with an SQL-error and
>> you have the lucky job to manualy correct that database.
>>
>> Regards
>> Beat
>>
>>
>> Am Montag, 11. Mai 2015 21:24 CEST, David Sporer
>> <david.sporer at gmail.com> schrieb:
>>   Hi Jan,
>>
>> the difference between doctrine:update and doctrine:migrate is (as far
>> as I know) that doctrine:update just goes through all your models,
>> checks if there are any properties defined in the model that are not
>> yet in the database and creates them.
>> doctrine:migrate just executes all migrations that are located in the
>> Migration/Mysql folder of your package.
>> The preferred workflow is as soon as you made changes to your models,
>> execute doctrine:migrationgenerate. This will create a migration-file
>> inside the Data/DoctrineMigrations folder.
>> You should now check if the migration folder creates everything as you
>> want it to and update the file if necessary (e.g. if you have an old
>> field that you want to move data over to the new one).
>>
>> Afterwards copy the automatically generated file to the
>> Migration/Mysql folder of your package and execute doctrine:migrate.
>> This will then add or update the fields in the database.
>>
>> You should always use doctrine:migrate instead of update because it
>> gives you much more control over what is happening in the background.
>> Also you can roll back changes and use the migrate-command for
>> automated deployment.
>>
>> Hope that helps a bit. I’m sure there are some things I forgot to
>> mention but maybe someone of the other guys can explain things in more
>> detail.
>>
>> Regards,
>> David
>>
>>> Am 11.05.2015 um 15:23 schrieb Jan Greth <jan at greth.me>:
>>>
>>> Hello Community!
>>>
>>> I have some problems understanding the whole Floe migrationcommand
>>> (doctrine:migrate, doctrine:migrationstatus,
>>> doctrine:migrationexecute, doctrine:migrationgenerate,
>>> doctrine:migrationversion, ...)thing and hope you can help me clear
>>> things out. So here are my questions:
>>>
>>> First, can you explain, what's the difference between
>>> doctrine:migrate and doctrine:update ?
>>>
>>> And to get in depth with the migration stuff: Can someone explain in
>>> simple words, what migrations in Flow are? When do i have to use it?
>>> And what ist the preferred Workflow?
>>>
>>> I often simply read "instead of using doctrine:update use
>>> doctrine:migrate"... why?
>>>
>>> I hope someone can help me,
>>> greetings,
>>> Jan
>>> _______________________________________________
>>> Flow mailing list
>>> Flow at lists.typo3.org
>>> http://lists.typo3.org/cgi-bin/mailman/listinfo/flow
>> _______________________________________________
>> Flow mailing list
>> Flow at lists.typo3.org
>> http://lists.typo3.org/cgi-bin/mailman/listinfo/flow
>> --
>>
>> Egli's frische Küchenkräuter AG
>> Beat Guggisberg
>> Informatik
>> Riedeggweg 70c
>> CH-3020 Riedbach
>>
>> direkt: +41 31 926 66 47
>> Zentrale: +41 31 926 66 66
>> Fax: +41 31 926 66 77
>> beat.guggisberg at eglionline.ch
>> www.eglionline.ch
>> _______________________________________________
>> Flow mailing list
>> Flow at lists.typo3.org
>> http://lists.typo3.org/cgi-bin/mailman/listinfo/flow
>