Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle schema changes #59

Closed
palkan opened this issue Feb 1, 2018 · 4 comments
Closed

Handle schema changes #59

palkan opened this issue Feb 1, 2018 · 4 comments

Comments

@palkan
Copy link
Owner

palkan commented Feb 1, 2018

We do not handle such cases, for example, as adding or removing columns. That might lead to undesired behaviour (see #58).

Some thoughts.

When a new column has been added, we might have no initial value for it (i.e. in the first version). Hence for the version prior to adding the column we should (either):

  • nullify it
  • set to default value (if any)
  • raise an error when it's read (thus mimic the old behaviour–undefined column).

Not sure which one is the right way.

@charlie-wasp
Copy link
Collaborator

For me the third option looks the most reasonable, however it might break some apps, using logidze already.

First two options are less reasonable (imho), because if there wasn’t a column at the certain point in time, so we shouldn’t pretend, that it was :)

Maybe we can implement first and third, and provide a switch between them for users.

What do you think, @palkan?

@palkan
Copy link
Owner Author

palkan commented Feb 6, 2018

Maybe we can implement first and third, and provide a switch between them for users.

Yeah, that make sense. And make the third to be a default.

@palkan
Copy link
Owner Author

palkan commented Feb 7, 2018

@dsalahutdinov
Copy link

Hello @palkan and @charlie-wasp
Could you please help with this issue sharing your suggestions about way of solving it.

Adding new column (the same case if we change column white list and regenerate triggers) causes starting to track changes of it.
If I've got right, somewhere here we need to determine that we do not have changes of that column. (but how?) All the knowledge about tracking columns list is in the sql triggers so we do not have the way to get it in ruby directly (because it is known only as options when we generate the model table triggers.

One way is to configure tracking columns list in the model class with dsl, and then generate the migration with help of this data, so in this case we will be able to track the case when versions history do not have changes of some column.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants