FAQ
I've been thinking about the best way to get easy migrations and with
minimal downtime.

The problem that happens when you alter a table is that some operations are
not safe, i.e. at renaming columns or
adding/removing columns at write models. More information here:

https://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/

So, my idea is to create a new table adding a suffix "_[VERSION]" at the
name of the table so the application is able to use the model's last
version with no downtime, while the data from older version are entered in
the new one (working in the background).
The issue is that every time it is needed a change, it is necessary to get
all data from a table (to CSV) for finally enter all them in the new
database. But I don't think that today this can be a great problem.

What do you think about it? Any idea?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Tamás Gulácsi at Jan 15, 2014 at 3:04 pm
    Use a db with transactional ddl operations (PostgreSQL)

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Archos at Jan 15, 2014 at 5:00 pm
    How do you think that the transactional operations fix this issue?
    I'm supposed that you did not not read the article; its author works in
    Heroku where they use PostgreSQL. Why were you supposing that the author
    was not using a full ACID compliant RDBMS?

    El miércoles, 15 de enero de 2014 15:04:41 UTC, Tamás Gulácsi escribió:
    Use a db with transactional ddl operations (PostgreSQL)
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tamás Gulácsi at Jan 16, 2014 at 12:31 pm
    Potgres provides a clean path: do everything required for the migration (alter, update) in ONe transaction, and commit on success, rollback on failure.

    This mitigates you from creating new temp tables, copying all data, then renaming.

    But of course leaves you with the problem of generating the migration steps.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Peter Bourgon at Jan 15, 2014 at 8:22 pm

    On Wed, Jan 15, 2014 at 2:54 PM, Archos wrote:
    I've been thinking about the best way to get easy migrations and with
    minimal downtime.
    For MySQL, there is the Large Hadron Migrator:
    https://github.com/soundcloud/lhm. Several other tools are linked at
    the bottom of the README.
    The problem that happens when you alter a table is that some operations are
    not safe, i.e. at renaming columns or
    adding/removing columns at write models. More information here:

    https://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/

    So, my idea is to create a new table adding a suffix "_[VERSION]" at the
    name of the table so the application is able to use the model's last version
    with no downtime, while the data from older version are entered in the new
    one (working in the background).
    The issue is that every time it is needed a change, it is necessary to get
    all data from a table (to CSV) for finally enter all them in the new
    database. But I don't think that today this can be a great problem.

    What do you think about it? Any idea?
    I think this probably has little to do with the golang-nuts mailing list. :)

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Archos at Jan 15, 2014 at 8:58 pm
    El miércoles, 15 de enero de 2014 20:22:25 UTC, Peter Bourgon escribió:
    On Wed, Jan 15, 2014 at 2:54 PM, Archos <raul...@sent.com <javascript:>>
    wrote:
    I've been thinking about the best way to get easy migrations and with
    minimal downtime.
    For MySQL, there is the Large Hadron Migrator:
    https://github.com/soundcloud/lhm. Several other tools are linked at
    the bottom of the README.
    The problem that happens when you alter a table is that some operations are
    not safe, i.e. at renaming columns or
    adding/removing columns at write models. More information here:

    https://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/
    So, my idea is to create a new table adding a suffix "_[VERSION]" at the
    name of the table so the application is able to use the model's last version
    with no downtime, while the data from older version are entered in the new
    one (working in the background).
    The issue is that every time it is needed a change, it is necessary to get
    all data from a table (to CSV) for finally enter all them in the new
    database. But I don't think that today this can be a great problem.

    What do you think about it? Any idea?
    I think this probably has little to do with the golang-nuts mailing list.
    :)
    It does when it's for a Go project:

    https://github.com/kless/modsql

    Thanks for the link although my vision to create and to handle the
    migrations is very different to how it's used by rails style migrations.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 15, '14 at 1:55p
activeJan 16, '14 at 12:31p
posts6
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase