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 t
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.
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 upgrad
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.xm
Yes, that (https://wiki.apache.org/solr/Atomic_Updates) would make
sense; thanks for the insight.
-Mike
On 3/15/2014 1:07 PM, Yonik Seeley wrote:
Perhaps so atomic updates work?
-Yonik
http://heliosearch.org - solve Solr GC pauses with off-heap filters
and fieldcache
On Sat, Mar 15, 2014 at
Perhaps so atomic updates work?
-Yonik
http://heliosearch.org - solve Solr GC pauses with off-heap filters
and fieldcache
On Sat, Mar 15, 2014 at 1:02 PM, Michael Sokolov
wrote:
> 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
