-
Notifications
You must be signed in to change notification settings - Fork 71
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
Islandora modules un/reinstall and upgrade process #1011
Comments
Updating a module where the actual configuration is changed as in the controlled_access_terms where the entire "type" was altered is going to be destructive. One of the reasons I would avoid adding too much to any non-Drupal standard field at this time is this variability. But I would also note that Alternatively if you are not using the |
@whikloj This is also @Natkeeran's point - detailed documentation of when re-installation is required or not, etc. and in fine detail, so that new to the platform will know how to proceed with confidence, especially during upgrades. |
Yes, you are right. uninstalling |
I think, once we have an initial release, the uninstall/install, migration pattern shouldn't be used at all. Proper upgrade hooks should be used instead. So, really, the PR that prompted this should have had an upgrade hook and would result in a new version being sliced. Generally speaking, I think most upgrades will simply require applying the PR and doing a feature import. This one is more involved because of a field-type change. |
@seth-shaw-unlv and I had some discussion on this topic. To have the option to cleanly update islandora and islandora_demo, we can possibly do the following. The basic idea is to recommend not to customize islandora and islandora_demo at all.
|
Good stuff @Natkeeran and @seth-shaw-unlv. I think the google doc you linked me could pretty easily go straight into the docs. By the end of it, we'll have a good "how to set up your repository" body of knowledge in the docs after folks start actively using this process. I take it this comes from experience at UTSC and UNLV? |
One of the pain points of CLAW has been updates. Anything we do now to ease that process will help manyfolds down the line. I believe @seth-shaw-unlv has a similar setup. We are on an earlier prototype with various custom content types. |
@Natkeeran @seth-shaw-unlv Did this knowledge make it into the documentation during the last sprint? |
@whikloj, I don't think so. No one signed up for the relevant slots on the sprint spreadsheet. |
Currently, there are three drupal modules for CLAW: islandora, islandora_demo, and
Islandora modules and controlled_access_terms that impact fields or have inter dependencies. That means, if we need to uninstall and reinstall these modules as part of an upgrade progress, things get complicated.
For instance, a recent change to controlled_access_terms required that module to be uninstalled and re installed. This mean, islandora_demo need to be uninstalled and reinstalled as well. Uninstalling and reinstalling means that any information in fields managed by these modules get deleted. Though this is not a major issue while in development, will become a major issue if we have to upgrade modules in production.
We need to get a clear understanding about when islandora modules need to be updated via uninstall/reinstall method and how to go about doing it. That process need to be documented well. We may need additional tooling to support this. We may have to consider tooling make the necessary database changes without uninstall/reinstall.
Many users do extend the metadata fields they use. Adding metadata fields should not require migration. However, modifing existing fields will require field or data migration. These processes need to be documented as well.
Also need direction with respect to how to use composer and ansible to manage these upgrades in production environments.
The text was updated successfully, but these errors were encountered: