[
https://jira.duraspace.org/browse/DS-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21669#comment-21669
]
Tim Donohue commented on DS-987:
--------------------------------
Hi Mark,
Not sure how to respond to your comments, as you just restated what I already
said (but, maybe I wasn't clear enough). My previous comments said that
although it'd be nice if we could treat [dspace]/solr/ like everything else and
back it up to /solr.bak, I realize this isn't possible as it contains your Solr
indexes (in /data directories). I fully understand this, and I also fully
understand that build.xml is only updating what is in
[dspace]/solr/[core]/conf/ and purposely leaving the /data directories alone
(as those contain your existing indexes).
I also said we should always backup the [dspace]/solr/[core]/conf/* files each
time we update them.
Again, my main concern here is that users may not realize that if they specify
"overwrite=false", that this will also cause Solr Schemas to not be upgraded
(users may not even realize that a "schema.xml.new" file was created under a
/solr/[core]/conf/ directory). Obviously, with our switch to default to
"overwrite=true", this is not as high a concern (as most users will likely
still choose to just run 'ant update' with default settings). But we still need
to be 100% clear with what the "overwrite" flag really is doing (currently the
description in 'ant help' and even in the Documentation is vague -- it doesn't
say anything about its control over upgrading Solr Schemas or even about the
[dspace]/solr/[core]/conf/ directories)
So, to be clear, I'm just questioning the current way the "overwrite" flag
works. I question whether this same flag should really control two separate
things: (1) whether your DSpace configs (in [dspace]/config/) are upgraded
automatically, and (2) whether your Solr Schemas (and everything in
/solr/[core]/conf/ directories) are upgraded. If we do want this flag to
control two separate things, then we need to improve our documentation &
description of what "overwrite=false" actually does.
Perhaps we just need to agree to disagree on this issue. As I already stated
above, by default in 1.8, the "overwrite" flag should still act similar to 1.7
(except, now it will default to "overwrite=true").
Since no one else is commenting here, I'm assuming most folks don't see this
flag as an issue of concern (which is fine...I just wanted to make sure I made
people aware of what the "overwrite" flag really is doing). We can always just
make this very clear in Documentation that running an "ant -Doverwrite=false
upgrade" means that you also need to closely check all
[dspace]/solr/[core]/conf/ directories to ensure all Solr Cores are upgraded
properly (otherwise you may encounter instability or odd behavior in either
Discovery or Solr Statistics or both)
> 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
