As much as possible, use new configs. Take fieldType definitions from your 4.x example dir, don't use the old ones. e.g. if you use the old date field type, it won't be usable in various ways (e.g. in the MS() function).
Upayavira On Thu, Jun 27, 2013, at 11:00 AM, Sandeep Gupta wrote: > Thanks again Shawn for your comments. > > I am little worried about the multi threading of web application which > uses > servlets. > > I also found one of your explanation (please confirm the same whether its > your comment only) in > http://lucene.472066.n3.nabble.com/Memory-problems-with-HttpSolrServer-td4060985.html > for the question : > http://stackoverflow.com/questions/11931179/httpsolrserver-instance-management > > As you said correctly that creation of SolrServer object depends on > number > of shards/solrcores and thereafter need to think for implementation which > may use singleton pattern. > > In my web application side, I have only one solrcore which is default > one > "collection1" so I will create one SolrServer object for my application. > Sure If we decide to go for Solr Cloud then also I will create one > object. > > Thanks Upayavira, yes I will do the re-index. Anything you want to > suggest > as you did the same migration. > > Thanks > Sandeep > > > > > > > > > > On Thu, Jun 27, 2013 at 1:33 PM, Upayavira <u...@odoko.co.uk> wrote: > > > I have done this - upgraded a 1.4 index to 3.x then on to 4.x. It > > worked, but... > > > > New field types have been introduced over time that facilitate new > > functionality. To continue to use an upgraded index, you need to > > continue using the old field types, and thus loose some of the coolness > > of newer versions. > > > > So, a re-index will set you in far better stead, if it is at all > > possible. > > > > Upayavira > > > > On Tue, Jun 25, 2013, at 06:37 PM, Erick Erickson wrote: > > > bq: I'm not sure if Solr 4.3 will be able to read Solr 1.4 indexes > > > > > > Solr/Lucene explicitly try to read _one_ major revision backwards. > > > Solr 3.x should be able to read 1.4 indexes. Solr 4.x should be > > > able to read Solr 3.x. No attempt is made to allow Solr 4.x to read > > > Solr 1.4 indexes, so I wouldn't even try. > > > > > > Shalin's comment is best. If at all possible I'd just forget about > > > reading the old index and re-index from scratch. But if you _do_ > > > try upgrading 1.4 -> 3.x -> 4.x, you probably want to optimize > > > at each step. That'll (I think) rewrite all the segments in the > > > current format. > > > > > > Good luck! > > > Erick > > > > > > On Tue, Jun 25, 2013 at 12:59 AM, Shalin Shekhar Mangar > > > <shalinman...@gmail.com> wrote: > > > > You must carefully go through the upgrade instructions starting from > > > > 1.4 upto 4.3. In particular the instructions for 1.4 to 3.1 and from > > > > 3.1 to 4.0 should be given special attention. > > > > > > > > On Tue, Jun 25, 2013 at 11:43 AM, Sandeep Gupta <gupta...@gmail.com> > > wrote: > > > >> Hello All, > > > >> > > > >> We are planning to migrate solr 1.4 to Solr 4.3 version. > > > >> And I am seeking some help in this side. > > > >> > > > >> Considering Schema file change: > > > >> By default there are lots of changes if I compare original Solr 1.4 > > schema > > > >> file to Sol 4.3 schema file. > > > >> And that is the reason we are not copying paste of schema file. > > > >> In our Solr 1.4 schema implementation, we have some custom fields > > with type > > > >> "textgen" and "text" > > > >> So in migration of these custom fields to Solr 4.3, should I use > > type of > > > >> "text_general" as replacement of "textgen" and > > > >> "text_en" as replacement of "text"? > > > >> Please confirm the same. > > > > > > > > Please check the text_general definition in 4.3 against the textgen > > > > fieldtype in Solr 1.4 to see if they're equivalent. Same for text_en > > > > and text. > > > > > > > >> > > > >> Considering Solrconfig change: > > > >> As we didn't have lots of changes in 1.4 solrconfig file except the > > > >> dataimport request handler. > > > >> And therefore in migration side, we are simply modifying the Solr 4.3 > > > >> solrconfig file with his request handler. > > > > > > > > And you need to add the dataimporthandler jar into Solr's lib > > > > directory. DIH is not added automatically anymore. > > > > > > > >> > > > >> Considering the application development: > > > >> > > > >> We used all the queries as BOOLEAN type style (was not good) I mean > > put > > > >> all the parameter in query fields i.e > > > >> *:* AND EntityName: <<>> AND <fileName>:<fieldValue> AND ..... > > > >> > > > >> I think we should simplify our queries using other fields like df, qf > > .... > > > >> > > > > > > > > Probably. AND queries are best done by filter queries (fq). > > > > > > > >> We also used to create Solr server object via CommonsHttpSolrServer() > > so I > > > >> am planning to use now HttpSolrServer API> > > > > > > > > Yes. Also, there was a compatibility break between Solr 1.4 and 3.1 in > > > > the javabin format so old clients using javabin won't be able to > > > > communicate with Solr until you upgrade both solr client and solr > > > > servers. > > > > > > > >> > > > >> Please let me know the suggestion for above points also what are the > > other > > > >> factors I need to take care while considering the migration. > > > > > > > > There is no substitute for reading the upgrade sections in the > > changes.txt. > > > > > > > > I'm not sure if Solr 4.3 will be able to read Solr 1.4 indexes. You > > > > will most likely need to re-index your documents. > > > > > > > > You should also think about switching to SolrCloud to take advantage > > > > of its features. > > > > > > > > -- > > > > Regards, > > > > Shalin Shekhar Mangar. > >
