[
https://jira.duraspace.org/browse/DS-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21659#comment-21659
]
Tim Donohue commented on DS-987:
--------------------------------
Mark,
Just to clarify about #2. I didn't mean to suggest we would always overwrite
the schema.xml without first backing it up. I think we should first backup the
existing file, and then overwrite it. So, you should still be able to
customize those schemas locally, if you wanted to.
But, I still wonder if we need to treat the Solr Schema similar to the Database
Schema (and less like a "configuration"). Sure, you can locally customize the
DB Schema too -- but, we still don't give you the option of not upgrading it
properly when you upgrade DSpace. Similarly, I wonder if we should allow local
Solr Schema changes to happen, but we always copy your changes off to a
'schema.xml.old' file and auto-upgrade your schema.xml (to ensure it is always
"compliant" with the latest version of DSpace).
So, I personally still question whether the "overwrite" flag should even apply
to the stuff in [dspace]/solr/ Technically, I'd want to treat [dspace]/solr/
more like all the other directories in [dspace] (like /lib and /webapps), but
as it contains your existing Solr Indexes, it'd be too much of a hassle to
create a [dspace]/solr.bak directory (similar to everything else, except
[dspace]/config). So, the next best thing is to just backup its contents to
*.old files and replace them in place.
Again...I'd like to hear what others think. By default, we probably should
just let "overwrite" continue to control the Solr schemas (as that is how it
works now). But, I still worry about that decision, as I'm not sure everyone
will understand the implications of setting "overwrite=false" (in that it
actually will mean that you must manually upgrade all of your Solr Schemas --
otherwise, you may encounter instability or oddity in either Discovery or Solr
Statistics).
> By default, Solr Schemas & Configs don't upgrade properly & may cause
> instability
> ---------------------------------------------------------------------------------
>
> Key: DS-987
> URL: https://jira.duraspace.org/browse/DS-987
> Project: DSpace
> Issue Type: Bug
> Components: Solr
> Affects Versions: 1.7.0, 1.7.1, 1.7.2
> Environment: Any environment
> Reporter: Tim Donohue
> Priority: Major
> Fix For: 1.8.0
>
>
> By default, if users run simply 'ant update' to upgrade a DSpace instance,
> the Solr Configurations & Schemas will NOT upgrade properly. (Note: However,
> if you run 'ant -Doverwrite=true update', then Solr will upgrade properly)
> The reason, is that DSpace's Solr directory updates it configurations similar
> to the [dspace]/config/ directory.
> So, if you simply run 'ant update', all your existing, older Solr Schemas &
> Configurations will remain in place unchanged (and new configs/schemas will
> be suffixed with ".new", e.g. schema.xml.new). This could cause instability
> in DSpace if users are accidentally using an old Solr schemas/configurations
> with a new DSpace API.
> I think we need to always overwrite existing Solr Schemas & Configurations.
> If we want to keep around a copy of older Solr Schemas, they should be
> suffixed with "-[date].old" (like when running 'ant -Doverwrite=true
> update'). As users are less likely to customize Solr Schemas/Configs
> (without knowing what they are doing), I think it's better to default to
> overwriting these files during an upgrade.
> As it stands, most users will not even realize there are Solr configurations
> under [dspace]/solr/search/conf/ and [dspace]/solr/statistics/conf/ which may
> not have upgraded properly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it.
http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
