| Hi,
There are two main differences (at least):
1) Migrations gives you the guarantee that the code is run only once in your app cluster. didFinishLaunching runs every time an instance starts, on all instances. So you need to write code to make sure that only one instance runs the code, and only once. Migrations give you that for free.
2) You need to remove or disable the code in didFinish after you don't need it anymore. In migrations, you don't, you can leave the code there for future reference, because it will never run again.
Regards,
Miguel Arroz On Jun 28, 2014, at 15:56, Hugi Thordarson < email@hidden> wrote: How is that different from just running tasks from e.g. Application.didFinishLaunching()? Can you run migrations without starting your entire application?
- hugi
On 29 Jun 2014, at 8:04 am, Miguel Arroz < email@hidden> wrote: Can't you use Wonder migrations? I have the vague recollection I did that on a past life for doing tasks like that. AFAIK there were two methods you could define on a migration, the first before EOF loaded the models, and the second one after. But I don't touch that for quite some time now, so I may be confused.
Yeah, I’ve certainly been known to do some one-time EOF-related tasks in a migration class—you can leave upgrade() and downgrade() empty, make sure you implement IERXPostMigration, and run the code in postUpgrade(). As for how dirty that makes you feel, I guess it’s a case-by-case basis. I’ve justified it from time to time because the postUpgrade() one-time tasks were model-related, and didn’t feel like a terrible abuse of migrations. YMMV
|