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

DB schema change desires #43

Open
5 tasks
jrochkind opened this issue Oct 1, 2014 · 0 comments
Open
5 tasks

DB schema change desires #43

jrochkind opened this issue Oct 1, 2014 · 0 comments

Comments

@jrochkind
Copy link
Member

I intentionally did not make any DB schema changes in Umlaut in the 4.0 release, in order to keep the upgrade to 4.0 as easy as possible.

But there are a number of schema changes that have suggested themselves. I would like to try to bundle them all together in one future Umlaut upgrade with one migration. @scotdalton and others, please feel free to add to this list.

  • ServiceResponse.url is 1024 chars. It needs to be much longer, or text
  • ServiceResponse.display_text should also potentially be longer
  • Request tries to keep a serialized HTTP_ENV hash in one column. It should not do this, but should take out the individual ENV/headers it needs in separate columns, each of which need to be 4096 or longer or just text. One of these should definitely be the original request path.
  • Permalink should keep the original request path in a string (new column), not just reconstruct it from a referrer
  • Referent has some 'mirror' columns directly in the referents table, that really duplicate values in associated referent_values. This was meant to be an aid for debugging and/or efficiency for finding 'equivalent' referents, but has not been used, and makes logic more complicated to keep them in sync. Remove them.

Future Umlaut version will distribute with TWO migrations, a non-destructure one (that you can run while still running old Umlaut, it does not remove any data columns old Umlaut needs but may add some additional ones), and a second destructive one that removes those columns (to be run after upgrade is complete). Second migration will not be installed automatically. To make upgrade with no downtime easier.

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

No branches or pull requests

1 participant