[
https://issues.apache.org/jira/browse/SOLR-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679045#comment-13679045
]
Alan Woodward commented on SOLR-4910:
-------------------------------------
bq. I'm glad it's going away
Well, it isn't really, is it? The point of persistence is to make sure that
changes made by the CoreAdminHandler (creations, deletions, renames, aliases
and swaps, plus splits and merges which are special cases of create/delete) are
still there after you restart. And this is the case both if you're writing
everything into solr.xml or if you're updating a core.properties file.
What would be really good here would be to split persistence policies out into
separate classes, one for writing to solr.xml and one for writing
core.properties. For solr.xml, the only mutable part is the cores list - we
can store the surrounding part as a plain String, which means a) we don't need
to worry about reconstructing things from a DOM, so we're guaranteed that we'll
always write out what we read in, and b) we can preserve things like XML
comments. The core.properties version just writes out any non-default
properties, subject to the rules that Shawn outlined above.
The persistor (CoreDescriptorPersistor maybe? Mmm, euphonious...) would belong
to the CoreContainer, which can then call persistor.persist(CoreDescriptor)
after each relevant operation. CoreAdminHandler doesn't need to care about it,
and we remove persist and persistFile as public methods of CoreContainer which
reduces it's surface area a bit.
CoreContainer, CoreDescriptor, CoreAdminHandler and ConfigSolr are all a bit
leaky at the moment. I think this is a good opportunity to patch up some of
these abstractions.
> solr.xml persistence is completely broken
> -----------------------------------------
>
> Key: SOLR-4910
> URL: https://issues.apache.org/jira/browse/SOLR-4910
> Project: Solr
> Issue Type: Bug
> Affects Versions: 5.0, 4.4
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Blocker
>
> I'm working on SOLR-4862 (persisting a created core doesn't preserve some
> values) and at least compared to 4.3 code, persisting to solr.xml is
> completely broken.
> I learned to hate persistence while working on SOLR-4196 & etc. and I'm glad
> it's going away. I frequently got lost in implicit properties (they're easy
> to persist and shouldn't be), what should/shouldn't be persisted (e.g. the
> translated ${var:default} or the original), and it was a monster, so don't
> think I'm nostalgic for the historical behavior.
> Before I dive back in I want to get some idea whether or not the current
> behavior was intentional or not, I don't want to go back into that junk only
> to undo someone else's work.
> Creating a new core (collection2 in my example) with persistence turned on in
> solr.xml for instance changes the original definition for collection1 (stock
> 4.x as of tonight) from this:
> <core name="collection1" instanceDir="collection1" shard="${shard:}"
> collection="${collection:collection1}" config="${solrconfig:solrconfig.xml}"
> schema="${schema:schema.xml}"
> coreNodeName="${coreNodeName:}"/>
> to this:
> <core loadOnStartup="true" shard="${shard:}" instanceDir="collection1/"
> transient="false" name="collection1" dataDir="data/"
> collection="${collection:collection1}">
> <property name="name" value="collection1"/>
> <property name="config" value="solrconfig.xml"/>
> <property name="solr.core.instanceDir" value="solr/collection1/"/>
> <property name="transient" value="false"/>
> <property name="schema" value="schema.xml"/>
> <property name="loadOnStartup" value="true"/>
> <property name="solr.core.schemaName" value="schema.xml"/>
> <property name="solr.core.name" value="collection1"/>
> <property name="solr.core.dataDir" value="data/"/>
> <property name="instanceDir" value="collection1/"/>
> <property name="solr.core.configName" value="solrconfig.xml"/>
> </core>
> So, there are two questions:
> 1> what is correct for 4.x?
> 2> do we care at all about 5.x?
> As much as I hate to say it, I think that we need to go back to the 4.3
> behavior. It might be as simple as not persisting in the <property> tags
> anything already in the original definition. Not quite sure what to put where
> in the newly-created core though, I suspect that the compact <core + attribs>
> would be best (assuming there's no <property> tag already in the definition.
> I really hate the mix of attributes on the <core> tag and <property> tags,
> wish we had one or the other....
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
