Re: Migrations: Adding mandatory relation?

On Feb 16, 2013, at 11:04 AM, Pascal Robert wrote:

> 
> Le 2013-02-16 à 12:53, Ramsey Gurley <[email protected]> a écrit :
> 
>> Hi All,
>> 
>> How do you add a mandatory relationship with a migration? If I were to do this manually, I'd create an optional FK, populate the FK column with the correct data, alter the table to make the FK mandatory, and add an FK constraint.
>> 
>> I can't do that with migrations, because the populate step has to happen at the end with a post migration.
>> 
>> I see with ERXMigration, I can do this with custom sql, but then that sucks too. I have to have essentially a Model_DB.sql file for every single database, which I really don't care to do. I could waste my weekend doing this for the databases I use, but then I eliminate the framework as an option for people who use DBs that I don't, like MySQL.
> 
> I would do that, and for databases that you don't use, ask people to contribute the required SQL for their own RDBMS. 


Thanks for the input Pascal. I was afraid that was the answer I would get.

There's one person using this framework, so you probably know which framework I'm talking about. And he uses MySQL. So by doing it this way, I not only force him to do this, but now I've forced anyone who might be interested in the framework to do it for their DB too.

If I update the migration, he's still forced to manually fix his data, or fork… so he's not really any better off either way. However, others who might be interested won't be put off by the requirement to contribute custom sql for their DB of choice.

No good answers here I'm afraid :-/ This is one thing I really, really don't like about WebObjects. There's no built in DB migration strategy and the one supplied by wonder is incomplete. The result is a data model that gets set in stone, or at least mud. Early mistakes are difficult to fix, perpetuated, and require daft workarounds in code forever. 

Personally, I'd rather have a complete EOF migrations strategy than all the jQuery frameworks in the world. It literally took me longer to compose this email than it took me to fix the problem by updating migration0.


> This is what I do when I add a column that should be not null but already have data: I create a migration that creates the column but allows NULLs (the model DON'T allow nulls) and I run a script to  run a UPDATE statement to populate the new column and a ALTER TABLE to mark the column as not accepting NULLs.
> 
> In your case, I think you can do it with two migrations, one to create the FK column and call the SQL script with the UPDATE statement, and one migration to add the constraint.
> 
>> Or I could take five minutes, regen the Migration0 and tell the whoever is using the framework to fork if they really can't lose their data.
>> 
>> None of these options are very appealing, but I'm leaning to the last one. Am I missing some secret Migration foo that would help me here?
>> 
>> Ramsey
>> 
>> 
>> ------------------------------------------------------------------------------
>> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
>> is your hub for all things parallel software development, from weekly thought 
>> leadership blogs to news, videos, case studies, tutorials, tech docs, 
>> whitepapers, evaluation guides, and opinion stories. Check out the most 
>> recent posts - join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Wonder-disc mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/wonder-disc
> 


------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/