Re: Portability of Solr index
Hi Mukesh, This seems like something lucene developers should be aware of - you have probably spent quiet some time to find problem/solution. Could you create a JIRA ticket? Roman On 10 May 2013 03:29, "mukesh katariya" wrote: > There is a problem with Base64 encoding. There is a project specific > requirement where i need to do some processing on solr string field type > and > then base64 encode it. I was using Sun's base64 encoder which is dependent > on the JRE of the system. So when i used to index the base64 it was adding > system specific new line character after every 77 characters. I googled a > bit and changed the base64 encoder to apache codec for base64 encoding. > this fixed the problem. > > > Thanks for all your time and help. > > Best Regards > Mukesh Katariya > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Portability-of-Solr-index-tp4061829p4062230.html > Sent from the Solr - User mailing list archive at Nabble.com. >
Re: Portability of Solr index
There is a problem with Base64 encoding. There is a project specific requirement where i need to do some processing on solr string field type and then base64 encode it. I was using Sun's base64 encoder which is dependent on the JRE of the system. So when i used to index the base64 it was adding system specific new line character after every 77 characters. I googled a bit and changed the base64 encoder to apache codec for base64 encoding. this fixed the problem. Thanks for all your time and help. Best Regards Mukesh Katariya -- View this message in context: http://lucene.472066.n3.nabble.com/Portability-of-Solr-index-tp4061829p4062230.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Portability of Solr index
What is the query/term you are looking for? I wonder if the difference is due to newline treatment on different platforms. Regards, Alex. Personal blog: http://blog.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 Thu, May 9, 2013 at 1:49 AM, mukesh katariya wrote: > I have built a SOLR Index on Windows 7 Enterprise, 64 Bit. I copy the index > to Centos release 6.2, 32 Bit OS. > > The index is readable and the application is able to load data from the > index on Linux. But there are a few fields on which FQ Queries dont work on > Linux , but same FQ Query work on windows. > > I have a situation where in i have to prepare index on windows and port it > on Linux. I need the index to be portable. > > The only thing which is not working is the FQ Queries. > > Inside the BlockTreeTermsReader seekExact API, I have enabled debugging and > system out statements scanToTermLeaf: block fp=1705107 prefix=0 nextEnt=0 > (of 167) > target=1RD0JIHMr9aw4RPPuS0DVzB2tKf38FfjKaEg7HsYDd7EtAOpE9FYvvj5ryB7679r4KNnlIazevPo > h7qabtLhXw== [31 52 44 30 4a 49 48 4d 72 39 61 77 34 52 50 50 75 53 30 44 56 > 7a 42 32 74 4b 66 33 38 46 66 6a 4b 61 45 67 37 48 73 59 44 64 37 45 74 41 > 4f 70 45 39 46 59 76 76 6a 35 72 79 42 37 36 37 39 72 34 4b 4e 6e 6c 49 61 > 7a 65 76 50 6f d a 68 37 71 61 62 74 4c 68 58 77 3d 3d] term= [] This is a > Term Query, and target bytes to match > > As per the algorithm it runs through the term and tries to match , now the > 6th term is a exact match, but there is a problem of few bytescycle: term 6 > (of 167) > suffix=1RD0JIHMr9aw4RPPuS0DVzB2tKf38FfjKaEg7HsYDd7EtAOpE9FYvvj5ryB7679r4KNnlIazevPo > h7qabtLhXw== [31 52 44 30 4a 49 48 4d 72 39 61 77 34 52 50 50 75 53 30 44 56 > 7a 42 32 74 4b 66 33 38 46 66 6a 4b 61 45 67 37 48 73 59 44 64 37 45 74 41 > 4f 70 45 39 46 59 76 76 6a 35 72 79 42 37 36 37 39 72 34 4b 4e 6e 6c 49 61 > 7a 65 76 50 6f a 68 37 71 61 62 74 4c 68 58 77 3d 3d] Prefix:=0 Suffix:=89 > target.offset:=0 target.length :=90 targetLimit :=89 > > from the first comment 50 6f d a 68 37 from the second comment 50 6f a 68 > 37. The test scenario is the index is built on linux and i am testing the > index through solr api on windows machine. > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Portability-of-Solr-index-tp4061783.html > Sent from the Solr - User mailing list archive at Nabble.com.
Portability of Solr index
I have built a SOLR Index on Windows 7 Enterprise, 64 Bit. I copy the index to Centos release 6.2, 32 Bit OS. The index is readable and the application is able to load data from the index on Linux. But there are a few fields on which FQ Queries dont work on Linux , but same FQ Query work on windows. I have a situation where in i have to prepare index on windows and port it on Linux. I need the index to be portable. The only thing which is not working is the FQ Queries. Inside the BlockTreeTermsReader seekExact API, I have enabled debugging and system out statements scanToTermLeaf: block fp=1705107 prefix=0 nextEnt=0 (of 167) target=1RD0JIHMr9aw4RPPuS0DVzB2tKf38FfjKaEg7HsYDd7EtAOpE9FYvvj5ryB7679r4KNnlIazevPo h7qabtLhXw== [31 52 44 30 4a 49 48 4d 72 39 61 77 34 52 50 50 75 53 30 44 56 7a 42 32 74 4b 66 33 38 46 66 6a 4b 61 45 67 37 48 73 59 44 64 37 45 74 41 4f 70 45 39 46 59 76 76 6a 35 72 79 42 37 36 37 39 72 34 4b 4e 6e 6c 49 61 7a 65 76 50 6f d a 68 37 71 61 62 74 4c 68 58 77 3d 3d] term= [] This is a Term Query, and target bytes to match As per the algorithm it runs through the term and tries to match , now the 6th term is a exact match, but there is a problem of few bytescycle: term 6 (of 167) suffix=1RD0JIHMr9aw4RPPuS0DVzB2tKf38FfjKaEg7HsYDd7EtAOpE9FYvvj5ryB7679r4KNnlIazevPo h7qabtLhXw== [31 52 44 30 4a 49 48 4d 72 39 61 77 34 52 50 50 75 53 30 44 56 7a 42 32 74 4b 66 33 38 46 66 6a 4b 61 45 67 37 48 73 59 44 64 37 45 74 41 4f 70 45 39 46 59 76 76 6a 35 72 79 42 37 36 37 39 72 34 4b 4e 6e 6c 49 61 7a 65 76 50 6f a 68 37 71 61 62 74 4c 68 58 77 3d 3d] Prefix:=0 Suffix:=89 target.offset:=0 target.length :=90 targetLimit :=89 from the first comment 50 6f d a 68 37 from the second comment 50 6f a 68 37. The test scenario is the index is built on linux and i am testing the index through solr api on windows machine. -- View this message in context: http://lucene.472066.n3.nabble.com/Portability-of-Solr-index-tp4061783.html Sent from the Solr - User mailing list archive at Nabble.com.
Portability of Solr index
I have built a SOLR Index on Windows 7 Enterprise, 64 Bit. I copy the index to Centos release 6.2, 32 Bit OS. The index is readable and the application is able to load data from the index on Linux. But there are a few fields on which FQ Queries dont work on Linux , but same FQ Query work on windows. I have a situation where in i have to prepare index on windows and port it on Linux. I need the index to be portable. The only thing which is not working is the FQ Queries. Inside the BlockTreeTermsReader seekExact API, I have enabled debugging and system out statements scanToTermLeaf: block fp=1705107 prefix=0 nextEnt=0 (of 167) target=1RD0JIHMr9aw4RPPuS0DVzB2tKf38FfjKaEg7HsYDd7EtAOpE9FYvvj5ryB7679r4KNnlIazevPo h7qabtLhXw== [31 52 44 30 4a 49 48 4d 72 39 61 77 34 52 50 50 75 53 30 44 56 7a 42 32 74 4b 66 33 38 46 66 6a 4b 61 45 67 37 48 73 59 44 64 37 45 74 41 4f 70 45 39 46 59 76 76 6a 35 72 79 42 37 36 37 39 72 34 4b 4e 6e 6c 49 61 7a 65 76 50 6f d a 68 37 71 61 62 74 4c 68 58 77 3d 3d] term= [] This is a Term Query, and target bytes to match As per the algorithm it runs through the term and tries to match , now the 6th term is a exact match, but there is a problem of few bytescycle: term 6 (of 167) suffix=1RD0JIHMr9aw4RPPuS0DVzB2tKf38FfjKaEg7HsYDd7EtAOpE9FYvvj5ryB7679r4KNnlIazevPo h7qabtLhXw== [31 52 44 30 4a 49 48 4d 72 39 61 77 34 52 50 50 75 53 30 44 56 7a 42 32 74 4b 66 33 38 46 66 6a 4b 61 45 67 37 48 73 59 44 64 37 45 74 41 4f 70 45 39 46 59 76 76 6a 35 72 79 42 37 36 37 39 72 34 4b 4e 6e 6c 49 61 7a 65 76 50 6f a 68 37 71 61 62 74 4c 68 58 77 3d 3d] Prefix:=0 Suffix:=89 target.offset:=0 target.length :=90 targetLimit :=89 from the first section 50 6f d a 68 37 from the second section 50 6f a 68 37. The test scenario is the index is built on linux and i am testing the index through solr api on windows machine. -- View this message in context: http://lucene.472066.n3.nabble.com/Portability-of-Solr-index-tp4061794.html Sent from the Solr - User mailing list archive at Nabble.com.
