That's a good point -- we may not really need to bother with all that.
I guess I tend to do it partly as a way to become aware of new features.
Well, sometimes there are required additions to the schema. For
example, the _version_ field was added at some time, and you really do
need it. I think that's the NRT support? I don't recall having to do
anything else to enable it, but perhaps I did. Hmm as I look through my
diffs I see that I enabled NRTCachingDirectoryFactory. I do find that
reviewing config changes tends to bubble up useful changes.
Another thing is that we do generally want to increase the version
number so as to benefit from bug fixes/enhancements in the components
that rely on that (like analysis, especially).
-Mike
On 03/16/2014 09:15 PM, Alexandre Rafalovitch wrote:
What do you expect to get out of updates except for
stability/new-features? In schema.xml, there is a version field. If
you don't change that, you should not be affected by new defaults. As
to new features (e.g. Near-Real-Time), you have to enable it
explicitly in couple of places to get it going.
I don't think restarting every upgrade from example schema is a good
idea. It has too much stuff in it. Perhaps, what we need is a separate
minimal example that would show just the basics. But then, what would
go into that (NRT support? dynamic schema?).
Regards,
Alex.
P.s. I am not disagreeing that the migration assistance would be
awesome. I am just trying to draw out more details from those doing it
in the trenches and make the discussion more concrete.
Personal website: http://www.outerthoughts.com/
LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
- Time is the quality of nature that keeps events from happening all
at once. Lately, it doesn't seem to be working. (Anonymous - via GTD
book)
On Sun, Mar 16, 2014 at 9:28 PM, Michael Sokolov
<msoko...@safaribooksonline.com> wrote:
Thanks for hunting that down, Jack. It may very well have been a change
that we made (to remove the stored="true". Sorry if I led you on a wild
goose chase.
Actually I wonder if people have a better method for performing config
upgrades than mine. I find that every time I take a Solr upgrade, I need to
do a point-by-point comparison of the new schema (and solrconfiig) with my
current one in order to upgrade the configuration while keeping my custom
fields, etc. plus there are all kinds of fields in the sample schema that I
don't really need: sku, manu, etc. which I typically remove just to cut down
on clutter. Does anyone have a script that uses svn to do this in a clever
way that they'd like to share?
-Mike
On 3/15/2014 4:52 PM, Jack Krupansky wrote:
Could it be that you had dropped a pre-4.2.1 schema into 4.2.1? I mean, I
just exhaustively examined all schema.xml changes between 4.2.1 and 4.6.1
(all 6 of them) and saw no wholesale change to stored="true". Maybe somebody
on your end removed a lot of fields from the 4.2.1 release of schema.xml.
Could you give a couple of examples of fields that changed from your 4.2.1
schema?
You can examine all changes yourself here:
http://svn.apache.org/viewvc/lucene/dev/tags/lucene_solr_4_2_1/solr/example/solr/collection1/conf/schema.xml?view=log
http://svn.apache.org/viewvc/lucene/dev/tags/lucene_solr_4_6_1/solr/example/solr/collection1/conf/schema.xml?view=log
-- Jack Krupansky
-----Original Message----- From: Michael Sokolov
Sent: Saturday, March 15, 2014 1:02 PM
To: solr-user@lucene.apache.org
Subject: example schema now stores most field values
While upgrading from 4.2.1 to 4.6.1 I noticed that many of the fields
defined in the example schema.xml that used to be indexed and not stored
are now defined as indexed and stored. Is there anything behind this
change other than the idea that it would be more convenient to have all
the values available? Is it somehow cheaper to recover them from the
index now, so that storing (ints, say) is free?
-Mike
