Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-1749

Graceful deprecation for different index update launcher commands

    Details

    • Type: Improvement
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 4.0
    • Fix Version/s: None
    • Component/s: Discovery
    • Labels:
      None
    • Attachments:
      0
    • Comments:
      6
    • Documentation Status:
      Needed

      Description

      In past versions there were 4 distinct launcher commands for updating search/browse indexes:

      index, index-init and index-update both operated on the Lucene based (old) browse and search indexes

      update-discovery-index takes care of initializing, cleaning and updating Discovery SOLR indexes.

      Now that Discovery, SOLR based search and browse has become the sole standard in DSpace 4, we should make sure that we gracefully get rid of the old launcher commands

        Attachments

          Issue Links

            Activity

            Hide
            bram Bram Luyten (@mire) added a comment -

            Here's one approach:

            https://github.com/bram-atmire/DSpace/commit/29ee9a7a2bb4724fd5bdedcc8152c0592f67b6b9

            This points all of the old commands to the code that updates the SOLR indexes.

            Show
            bram Bram Luyten (@mire) added a comment - Here's one approach: https://github.com/bram-atmire/DSpace/commit/29ee9a7a2bb4724fd5bdedcc8152c0592f67b6b9 This points all of the old commands to the code that updates the SOLR indexes.
            Hide
            tdonohue Tim Donohue added a comment -

            Hi Bram,

            We should discuss this more in this week's Developers Meeting (or via email).

            My opinion is that we should NOT entirely remove/replace these old (Lucene based) index scripts in 4.0. Even in 4.0, there is still the option to be able to disable Discovery and enable Lucene...so there still needs to be scripts that support Lucene indexing.

            But, we may want to think about possibly renaming / swapping the "index" scripts around so they make more sense with the new defaults. For example:

            • "dspace index" could be changed to index in Discovery (since that is now default)
            • We could then create a new "dspace index-lucene" (or some similar naming scheme) for folks who want to still use Lucene instead of Discovery, and make it clear in the docs that you need to use "index-lucene" if you wish to continue to use Lucene for Search.

            In general, I think the deprecation plan needs to be:
            1. Still fully support Lucene in 4.0, but likely deprecate its code/tools (as obviously Discovery is the new default)
            2. In DSpace 5.0, we can either remove plain Lucene support entirely, or we could rewrite the Lucene code so that it's another possible "backend" to Discovery. But, that's something that is still yet to be decided.

            Show
            tdonohue Tim Donohue added a comment - Hi Bram, We should discuss this more in this week's Developers Meeting (or via email). My opinion is that we should NOT entirely remove/replace these old (Lucene based) index scripts in 4.0. Even in 4.0, there is still the option to be able to disable Discovery and enable Lucene...so there still needs to be scripts that support Lucene indexing. But, we may want to think about possibly renaming / swapping the "index" scripts around so they make more sense with the new defaults. For example: "dspace index" could be changed to index in Discovery (since that is now default) We could then create a new "dspace index-lucene" (or some similar naming scheme) for folks who want to still use Lucene instead of Discovery, and make it clear in the docs that you need to use "index-lucene" if you wish to continue to use Lucene for Search. In general, I think the deprecation plan needs to be: 1. Still fully support Lucene in 4.0, but likely deprecate its code/tools (as obviously Discovery is the new default) 2. In DSpace 5.0, we can either remove plain Lucene support entirely, or we could rewrite the Lucene code so that it's another possible "backend" to Discovery. But, that's something that is still yet to be decided.
            Hide
            pottingerhj@umsystem.edu Hardy Pottinger added a comment -

            I like Tim's proposal of providing an alternate script for Lucene, I just wonder if perhaps we should consider letting the legacy (Lucene-supporting) script keep the name, and introduce a new script with a new name. That way existing cron jobs will still work post-upgrade, if an upgrading repository elects to disable Discovery.

            Show
            pottingerhj@umsystem.edu Hardy Pottinger added a comment - I like Tim's proposal of providing an alternate script for Lucene, I just wonder if perhaps we should consider letting the legacy (Lucene-supporting) script keep the name, and introduce a new script with a new name. That way existing cron jobs will still work post-upgrade, if an upgrading repository elects to disable Discovery.
            Hide
            tdonohue Tim Donohue added a comment -

            We discussed this topic in today's DSpace Developers Meeting:

            full logs: http://irclogs.duraspace.org/index.php?date=2013-11-13

            The general consensus was that we may just want to rename ALL of our Indexing scripts to clarify their usage/purpose.

            I've created a new ticket describing the proposed renaming at: DS-1788

            Show
            tdonohue Tim Donohue added a comment - We discussed this topic in today's DSpace Developers Meeting: full logs: http://irclogs.duraspace.org/index.php?date=2013-11-13 The general consensus was that we may just want to rename ALL of our Indexing scripts to clarify their usage/purpose. I've created a new ticket describing the proposed renaming at: DS-1788
            Hide
            bollini Andrea Bollini added a comment -

            as in Mark's comment
            https://jira.duraspace.org/browse/DS-1762?focusedCommentId=31291&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-31291

            "In DSpace 4.0, the index maintenance commands have been renamed to make their relationships to the Lucene indexing, Discovery indexing, and database-based browsing more clear.

            There has been some discussion of making these commands fail more gracefully, so I'm leaving this open for now and removing it from the 4.0 schedule."

            Show
            bollini Andrea Bollini added a comment - as in Mark's comment https://jira.duraspace.org/browse/DS-1762?focusedCommentId=31291&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-31291 "In DSpace 4.0, the index maintenance commands have been renamed to make their relationships to the Lucene indexing, Discovery indexing, and database-based browsing more clear. There has been some discussion of making these commands fail more gracefully, so I'm leaving this open for now and removing it from the 4.0 schedule."
            Hide
            tdonohue Tim Donohue added a comment -

            This ticket (based on its description) seems to have been resolved by DS-1788

            If there are further suggestions on improving how these index commands work (or what they report if they fail), we should open up a new ticket to describe those improvements.

            Show
            tdonohue Tim Donohue added a comment - This ticket (based on its description) seems to have been resolved by DS-1788 If there are further suggestions on improving how these index commands work (or what they report if they fail), we should open up a new ticket to describe those improvements.

              People

              • Assignee:
                Unassigned
                Reporter:
                bram Bram Luyten (@mire)
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: