ndexing fresh. You haven't
> said whether you have any custom code and the like, so that is an
> unknown.
>
> Best,
> Erick
> On Tue, Dec 11, 2018 at 6:28 AM hello hello wrote:
>
>
> Bonjour ,
>
> I am a project manager at La Poste française , I am managing a n
t; unknown.
>>
>> Best,
>> Erick
>> On Tue, Dec 11, 2018 at 6:28 AM hello hello wrote:
>>>
>>> Bonjour ,
>>>
>>> I am a project manager at La Poste française , I am managing a national
>&
;t
> said whether you have any custom code and the like, so that is an
> unknown.
>
> Best,
> Erick
> On Tue, Dec 11, 2018 at 6:28 AM hello hello wrote:
> >
> > Bonjour ,
> >
> > I am a project manager at La Poste française , I am managing a national
>
own.
Best,
Erick
On Tue, Dec 11, 2018 at 6:28 AM hello hello wrote:
>
> Bonjour ,
>
> I am a project manager at La Poste française , I am managing a national
> project using SORL 4.9 and I want to migrate to SOLR 7 .
> Can you give me a summary of all the spots that need to be do
Bonjour ,
I am a project manager at La Poste française , I am managing a national project
using SORL 4.9 and I want to migrate to SOLR 7 .
Can you give me a summary of all the spots that need to be done to make this
migration? Thank oyu your for help Fred
es a different stored fields format, but this
codec would not be supported in terms of backward compatibility. So you would
have to mave back to the default codec and then again to your custom codec on
every upgrade.
> IndexSearcher.doc(int docID, SetfieldsToLoad) is slower in Lucene 4.9 when
> c
4.x codec that does not use
CompressingStoredFieldsFormat?
> IndexSearcher.doc(int docID, SetfieldsToLoad) is slower in Lucene 4.9 when
> compared to Lucene 2.9
> --
>
>
rage scheme and move to binary docvalues, or so?
> IndexSearcher.doc(int docID, SetfieldsToLoad) is slower in Lucene 4.9 when
> compared to Lucene 2.9
> --
>
>
d in CompressingStoredFieldsReader.document.
> IndexSearcher.doc(int docID, SetfieldsToLoad) is slower in Lucene 4.9 when
> compared to Lucene 2.9
> --
>
> Key: LUCENE-6322
&g
Sekhar created LUCENE-6322:
--
Summary: IndexSearcher.doc(int docID, SetfieldsToLoad) is slower
in Lucene 4.9 when compared to Lucene 2.9
Key: LUCENE-6322
URL: https://issues.apache.org/jira/browse/LUCENE-6322
On Thu, Sep 25, 2014 at 3:01 AM, Gora Mohanty wrote:
> On 25 September 2014 12:03, 김승민80 wrote:
>> Long time ago, I made writing/reading program by using lucene.
>
> Please address this question to the solr-user list:
> solr-u...@lucene.apache.org
> where you are more likely to get help/
Hmm,
On 25 September 2014 12:03, 김승민80 wrote:
>
> Hello.
>
>
>
> Long time ago, I made writing/reading program by using lucene.
Please address this question to the solr-user list: solr-u...@lucene.apache.org
where you are more likely to get help/
The dev list is meant for development-related question
[
https://issues.apache.org/jira/browse/LUCENE-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Ernst resolved LUCENE-5927.
Resolution: Won't Fix
Yep, closing.
> 4.9 -> 4.10 change in StandardTokenizer behavio
hink simulating the old bug is
overkill because it just will not be useful).
Ryan, are you okay with resolving this issue as won't fix?
> 4.9 -> 4.10 change in StandardTokenizer behavior on \u1aa2
> --
>
>
5.x.
Analyzers have getVersion/setVersion and if we want to add
Lucene40StandardTokenizer and have them make use of this to emulate 4.0 (as
opposed to 4.6+) grammar, thats fine. With the API ryan has, it wont cause
users "pain" and keeps the back compat.
> 4.9 -> 4.10 change
#x27;t want changes; IMHO
everybody impacted by this change would want it, so I agree: we should do
nothing.
> 4.9 -> 4.10 change in StandardTokenizer behavior on \u1aa2
> --
>
> Key: LUCENE-5927
>
-specific implementations (as will be the case in 5.x)?
Thoughts?
> 4.9 -> 4.10 change in StandardTokenizer behavior on \u1aa2
> --
>
> Key: LUCENE-5927
> URL: https://issues.apache.
the relevant parts from the 4.9 grammar:
{noformat}
ContextSupp = ([]) // no supplementary characters in {{LB:ComplexContext}} in
Unicode 6.3
...
ComplexContext= (\p{LB:Complex_Context} | {ComplexContextSupp})
...
{ComplexContext}+ { return SOUTH_EAST_ASIAN_TYPE; }
{noformat}
and the 4.10 gramma
e
>doing downstream processing... and if you are doing that, its very good that
>this bug is fixed.
> 4.9 -> 4.10 change in StandardTokenizer behavior on \u1aa2
> --
>
> Key: LUCENE-5927
>
Ryan Ernst created LUCENE-5927:
--
Summary: 4.9 -> 4.10 change in StandardTokenizer behavior on \u1aa2
Key: LUCENE-5927
URL: https://issues.apache.org/jira/browse/LUCENE-5927
Project: Lucene - C
Problem using Solr 4.9 index with 4.10 build (merge failures with DocValues?)
> -
>
> Key: SOLR-6306
> URL: https://issues.apache.org/jira/browse/SOLR-6306
> Project:
[
https://issues.apache.org/jira/browse/SOLR-6306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Hoerner closed SOLR-6306.
---
Resolution: Invalid
> Problem using Solr 4.9 index with 4.10 build (merge failures with DocVal
ed.
> Problem using Solr 4.9 index with 4.10 build (merge failures with DocValues?)
> -
>
> Key: SOLR-6306
> URL: https://issues.apache.org/jira/browse/SOLR-630
it's reasonable. :)
I'm not sure on exact svn rev, but it was built with branch_4x as of that day
(6-16), which to me means something must have "fixed" the issue in here (6-16
up to 4.9 release, from git):
{code}
* 36c54b1 - (tag: lucene_solr_4_9_0) tag 4.9 Robert Muir (5 weeks ag
this:
lucene.version=4.9-SNAPSHOT Unversioned directory - brett - 2014-06-16 13:17:20
It looks like these were created with an unreleased version of 4.9? The index
format is not finalized until the final release, so that would explain why 4.10
cannot read it: we can only support backwards compatibi
two different collections (same
SolrCloud cluster) on different machines. In both cases I had existing shards
from 4.9 and I tried to index into them after running 4.10. Our data is sharded
by time and "rolls forward" and new shards created after 4.10 that don't have
any pre-4.10
the java version is "1.8.0".
But I will download your index for now and play and try to figure it out.
> Problem using Solr 4.9 index with 4.10 build (merge failures with DocValues?)
> -
>
>
e:
https://s3.amazonaws.com/massrel-pub/index.tar
checkindex output: https://s3.amazonaws.com/massrel-pub/checkindex.txt
> Problem using Solr 4.9 index with 4.10 build (merge failures with DocValues?)
> -
>
>
This will help narrow it down. Also, if data is not sensitive, can you supply
the index. I will debug the situation. In that case. Otherwise i am happy to
debug it here.
> Problem using Solr 4.9 index with 4.10 build (merge failures with Do
Brett Hoerner created SOLR-6306:
---
Summary: Problem using Solr 4.9 index with 4.10 build (merge
failures with DocValues?)
Key: SOLR-6306
URL: https://issues.apache.org/jira/browse/SOLR-6306
Project
VOTE has passed, I've triggered the svn publish to start the sync out to
the mirrors.
: Date: Thu, 26 Jun 2014 18:18:27 -0500
: From: Cassandra Targett
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Cc: Lucene mailing list
: Subject: VOTE: RC0 apache-solr-ref-guide-4.
+1
On Fri, Jun 27, 2014 at 4:48 AM, Cassandra Targett
wrote:
> The Solr Ref Guide for Solr 4.9 is ready for vote:
>
>
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-4.9-RC0/
>
> +1 from me.
>
> Cassandra
>
>
--
Regards,
Shalin Shekhar Mangar.
+1, thanks!
- Mark
On Thu, Jun 26, 2014 at 7:18 PM, Cassandra Targett
wrote:
> The Solr Ref Guide for Solr 4.9 is ready for vote:
>
>
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-4.9-RC0/
>
> +1 from me.
>
> Cassandra
>
>
tial, these can be folded into the respin.
Steve
On Jun 26, 2014, at 7:18 PM, Cassandra Targett wrote:
> The Solr Ref Guide for Solr 4.9 is ready for vote:
>
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-4.9-RC0/
>
>
:
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-4.9-RC0/
+1 to the following artifact...
$ cat apache-solr-ref-guide-4.9.pdf.sha1
e9076d896b2a99979a611e0972ac7da9b30a0a62 apache-solr-ref-guide-4.9.pdf
-Hoss
http://www.lucidworks.com
The Solr Ref Guide for Solr 4.9 is ready for vote:
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-4.9-RC0/
+1 from me.
Cassandra
Hi -
We're hoping to get a release candidate for the 4.9 version of the Solr Ref
Guide tonight or tomorrow morning, so I made a "pre-RC" PDF for review.
This isn't a vote and it's not a final version - there are still a few
items being worked on today.
http://pe
ate. Thus,
this feature is related to replication in SolrCloud.
Also, I'm happy to help out with any of the ManagedResource
refactoring work if we take that on in this release.
Tim
On Mon, Jun 23, 2014 at 10:23 AM, Cassandra Targett
wrote:
> The vote for Lucene/Solr 4.9 is underway and we n
The vote for Lucene/Solr 4.9 is underway and we need to get the Solr Ref
Guide updated for the new release.
I went through the CHANGES.txt for Solr on Friday and updated the TODO list
found at
https://cwiki.apache.org/confluence/display/solr/Internal+-+TODO+List. I
notice that many of the new
I created the branch here:
http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_9/
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
>> http://blog.mikemccandless.com
>>
>>
>> On Thu, Jun 12, 2014 at 9:56 PM, Robert Muir wrote:
>> > We have a pretty big release already with lots of good performance
>> > improv
t; > We have a pretty big release already with lots of good performance
> > improvements. I'd like to release 4.9 soon, ill be RM. I'm thinking of
> > spinning a RC in a week or so.
>
> -
> To unsu
+1
Mike McCandless
http://blog.mikemccandless.com
On Thu, Jun 12, 2014 at 9:56 PM, Robert Muir wrote:
> We have a pretty big release already with lots of good performance
> improvements. I'd like to release 4.9 soon, ill be RM. I'm thinking of
> spinning a
+1
On Fri, Jun 13, 2014 at 3:56 AM, Robert Muir wrote:
> We have a pretty big release already with lots of good performance
> improvements. I'd like to release 4.9 soon, ill be RM. I'm thinking of
> spinning a RC in a week o
{
Arun Kumar figured this out. Can you confirm this is truly a bug?
His above solution, fixes all three : SOLR-3193 SOLR-3901 SOLR-5426.
Thanks,
Ahmet
On Friday, June 13, 2014 4:56 AM, Robert Muir wrote:
We have a pretty big release already with lots of good performance
improvements. I
getting these patches considered for
>> inclusion?
>>
>> https://issues.apache.org/jira/browse/SOLR-5722
>> https://issues.apache.org/jira/browse/SOLR-2649
>>
>> Ta,
>> Greg
>>
>>
>>
>> On 13 June 2014 11:56, Robert Muir wrote:
>>
>
e.org/jira/browse/SOLR-5722
> https://issues.apache.org/jira/browse/SOLR-2649
>
> Ta,
> Greg
>
>
>
> On 13 June 2014 11:56, Robert Muir wrote:
>
>> We have a pretty big release already with lots of good performance
>> improvements. I'd like to release 4.9 soon, ill be RM. I'm thinking of
>> spinning a RC in a week or so.
>>
>
>
ood performance
> improvements. I'd like to release 4.9 soon, ill be RM. I'm thinking of
> spinning a RC in a week or so.
>
We have a pretty big release already with lots of good performance
improvements. I'd like to release 4.9 soon, ill be RM. I'm thinking of
spinning a RC in a week or so.
5743:
-
Commit 1601625 from [~rcmuir] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1601625 ]
LUCENE-5743: Add Lucene49NormsFormat
> new 4.9 norms format
>
>
> Key: LUCENE-5743
> URL: https://issues.apach
[
https://issues.apache.org/jira/browse/LUCENE-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-5743.
-
Resolution: Fixed
Fix Version/s: 5.0
4.9
I added the Arrays.sort
5743:
-
Commit 1601606 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1601606 ]
LUCENE-5743: Add Lucene49NormsFormat
> new 4.9 norms format
>
>
> Key: LUCENE-5743
> URL: https://issues.apache.org/jira/browse/LUCE
(e.g. SegmentInfo.files() set,
FieldInfos.attributes(), various other places in the index write unordered sets
where it does not matter), but we can add an Arrays.sort, this array is always
<= 256 elements.
> new 4.9 norms format
>
>
>
the {{uniqueValues.toArray()}} call doesn't guarantee any order
right? It doesn't look like it matters for correctness, but I would expect
idempotence from the format, at least for reproducibility of tests.
> new 4.9 norms format
>
>
> Key: LUCENE-
[
https://issues.apache.org/jira/browse/LUCENE-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021468#comment-14021468
]
Michael McCandless commented on LUCENE-5743:
+1
> new 4.9 norms
ly a generalization of the sparse case. I
wanted to tackle this, but decided against it here, the idea is to just improve
lucenes defaults. This patch handles sparsity to some extent via low bPV and
constant compression. Nothing sophisticated but I think effective enough as a
step.
> new 4.9 norms
ying that the norm is not there) and the other ones on disk?
> new 4.9 norms format
>
>
> Key: LUCENE-5743
> URL: https://issues.apache.org/jira/browse/LUCENE-5743
> Project: Lucene - Core
> Issue Type: New
[
https://issues.apache.org/jira/browse/LUCENE-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021333#comment-14021333
]
Adrien Grand commented on LUCENE-5743:
--
+1
> new 4.9 norms
):
Trunk: 158,279,213 bytes RAM
Patch: 36,446,880 bytes RAM
> new 4.9 norms format
>
>
> Key: LUCENE-5743
> URL: https://issues.apache.org/jira/browse/LUCENE-5743
> Project: Lucene - Core
> Is
Robert Muir created LUCENE-5743:
---
Summary: new 4.9 norms format
Key: LUCENE-5743
URL: https://issues.apache.org/jira/browse/LUCENE-5743
Project: Lucene - Core
Issue Type: New Feature
60 matches
Mail list logo
