-
Notifications
You must be signed in to change notification settings - Fork 79
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
Comments
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? |
Yeah, that make sense. And make the third to be a default. |
Btw, we can use AR missing attribute exception https://github.com/rails/rails/blob/8fd69db783b14dcdde92f4682b8d3c66bdbcb90b/activemodel/lib/active_model/attribute_methods.rb#L470 |
Hello @palkan and @charlie-wasp Adding new column (the same case if we change column white list and regenerate triggers) causes starting to track changes of it. 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. |
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):
Not sure which one is the right way.
The text was updated successfully, but these errors were encountered: