[
https://issues.apache.org/jira/browse/SOLR-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679879#comment-13679879
]
Mark Miller commented on SOLR-4910:
-----------------------------------
bq. is that the logic is spread out amongst a whole bunch of classes.
I agree - it's gotten quite difficult to deal with the persistence code.
At one point, I started trying to isolate the code a bit - in an attempt to
make testing easier - a fair bit was still left in CoreContainer still though.
The new stuff moved away from simply keeping the old dom in memory (I think we
still want to do that and actually reintroduced it at one point, though I
didn't move all the code to use it) and spread the code across a variety of new
classes.
I started a large refactoring wave on it actually, but there remains much to do
in general IMO. CoreContainer and all of this has started to grow unweildy.
Things will simplify some even with no effort I think - just not having to
support the two core discovery modes will make a better design easier.
In any case, I'm not so happy with the current state of things, but currently
two things have largely affected my thoughts on that:
1. I have not had much time to apply to this problem - I started a lot of work
a month or two back and have yet to come back to it.
2. We are dropping all this persistence stuff shortly in 5, as well as support
for the old style solr.xml.
So while we have a pressing needs for tests and fixes around solr.xml
persistence, anything else I consider just gravy that may slide off into the
trash when we release 5. Who doesn't love gravy if someone is willing to serve
it :) But I'd be almost as happy if we simply got this working as a start -
then if people want to improve it, patches welcome, but we get to clean slate
it in 5.0 anyway (when it comes to solr.xml persistence).
I do welcome any contributions or improvements - but until we actually nail
down the testing (this refactoring has exposed how few we have in these areas),
refacoring is pretty scary stuff.
> 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
>
>
> 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]
