Mailinglist Archive: opensuse-buildservice (123 mails)
< Previous | Next > |
Re: [opensuse-buildservice] Proposal to use data_migrate gem for API
- From: Evan Rolfe <esrolfe@xxxxxxx>
- Date: Mon, 11 Sep 2017 12:57:34 +0100
- Message-id: <62252feb-5f3a-d7d9-a591-a15d3f5d2bc7@suse.de>
On 11/09/17 12:43, Adrian Schröter wrote:
1. Include the script in a normal rails migration
=> Downside: the updaters will have the extra step of making sure that this particular migration is run without downtime (I dont know how that would even work?).
2. We use the data_migration gem
=> Downside: the updaters have to run a second command `rake data:migrate`
3. We use a rake task
=> Downside: the updaters have to run a rake task, and any future data changes will also require new rake tasks so there are potentially many more steps involved for updating as opposed to just one step: `rake data:migrate`.
I don't see how #1 is going to work but if you have an idea then I would be open to that too.
--
Evan Rolfe
Full Stack Web Developer
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg
Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx
Could we run the data modifications also always when "db:migrate"Yes I'm sure thats possible but it would defeat the purpose of having data migrations separate from database migrations.
is called?
That way you can opt-in to do data changes only, but we don't needI don't think we can avoid adding another command to the OBS version update process. If we want to update a table which has ~3million rows (project_log_entries) then the script to do that will at least an hour. So as I see it we have these three options (maybe there are alternatives?):
to teach people yet another command to run on next OBS version update.
1. Include the script in a normal rails migration
=> Downside: the updaters will have the extra step of making sure that this particular migration is run without downtime (I dont know how that would even work?).
2. We use the data_migration gem
=> Downside: the updaters have to run a second command `rake data:migrate`
3. We use a rake task
=> Downside: the updaters have to run a rake task, and any future data changes will also require new rake tasks so there are potentially many more steps involved for updating as opposed to just one step: `rake data:migrate`.
I don't see how #1 is going to work but if you have an idea then I would be open to that too.
--
Evan Rolfe
Full Stack Web Developer
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg
Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx
< Previous | Next > |