[
https://issues.apache.org/jira/browse/SOLR-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680131#comment-13680131
]
Erick Erickson commented on SOLR-4910:
--------------------------------------
bq (Alan): OK, I can see you want to hold off anything major if we're dropping
4.4 imminently, but I think it's really worth looking at rationalizing this
stuff
I completely agree, it's pretty clear that this grew organically and is a
hodgepodge at best. It's just that I'm pretty uncomfortable with the timing.
Once 4.4 is cut, particularly if we can do something very quickly after 4.4
goes out and that discomfort goes away. Much of my trepidation is that there's
some agitation for 4.4 in the very near future.
bq (Mark): We are dropping all this persistence stuff shortly in 5, as well as
support for the old style solr.xml.
You don't know how thrilled I am to be working on something that I _know_ is
going to be thrown out <G>.. But I'm feeling like I'm earning the right to be
the one who rips it out <GGG>.
bq (Mark): But I'd be almost as happy if we simply got this working as a start
Right, that's about all I intend to do on this. When 5.0 comes along and we'll
rip it entirely out. So I'm looking at just enough to get by the current
hurdles and declare victory.
The bulk of the effort in what I did tonight was figuring out how to verify
that all the nodes and attributes in one xml file are identical to another.
Please don't tell me something's already been written, I looked but didn't find
it. Of course what I made tonight is specialized to solr.xml and I suspect it
has some holes to flush out as the patch matures.
> 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
> Attachments: SOLR-4910.patch, SOLR-4910.patch
>
>
> 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]
