In the SortedDocValues.lookupOrd documentation it says that a deep
copy is needed for the returned BytesRef. I wanted to verify that this
was actually true. I'm
trying to see a way that this BytesRef could be safely reused by the
API but I don't see one. Is there actually an implementation of
Hi Joel,
You should trust the javadocs.
Looking at our default Codec on master (Lucene84Codec), and at its default
doc values implementation (Lucene80DocValuesProducer), it is clearly
reusing the private "BytesRef term" instance.
If your code is fully consuming this BytesRef before calling any
Thanks Christine!
I genuinely like this idea.
This actually gets us what we want without having to handle everything at
the same time, and also giving us time to see if the split is working or
not. This process also ensures that both, Lucene and Solr maintain the
symbiotic relationship at least
Perhaps Christine! That's a nice idea!
On naming, it would have to be probably something snazzier than "Search" as
you get at. It would probably not be a good trademark, and would imply that
Lucene & Solr are the only things in ASF that could be "Search". Who knows,
one day Vespa or something
Ok thanks, this makes sense. It's safe to use for the same SortedDocValues
instance until the method is called again. I think changing the javadoc to
the following will help clear up the confusion:
/** Retrieves the value for the specified ordinal. The returned
* {@link BytesRef} may be re-used
+1 (binding)
Tommaso
On Tue, 12 May 2020 at 09:37, Dawid Weiss wrote:
> Dear Lucene and Solr developers!
>
> According to an earlier [DISCUSS] thread on the dev list [2], I am
> calling for a vote on the proposal to make Solr a top-level Apache
> project (TLP) and separate Lucene and Solr
Yeah; I'm glad it seems it's fixed.
~ David
On Thu, May 14, 2020 at 8:32 AM Erick Erickson
wrote:
> Oh good, thanks for posting ‘cause I thought I’d screwed one up. Looks
> like it’s fixed now though?
>
> > On May 14, 2020, at 1:33 AM, David Smiley wrote:
> >
> > FYI
Are you are talking about these?
https://github.com/apache/lucene-solr/commit/ba0891415e9567bac96ace79013184aa039ac580
https://github.com/apache/lucene-solr/commit/ada8be1b45d97c45234b45ae00ddce3425631420
On Fri, May 15, 2020 at 3:41 AM Mike Drob wrote:
>
> Noble,
>
> We're still missing a
If it's something that happens with gradle then please report the
stack trace to when this is happening, otherwise it's hard to tell
what's going on and where.
Dawid
On Wed, May 13, 2020 at 8:17 PM Joel Bernstein wrote:
>
> Is anybody seeing the following error on pre-commit:
>
> JAR resource
> WDYT about making 3g the default (I volunteer)?
I honestly don't know what consumes so much memory in the daemon -
whether it's the caches or something else. It doesn't seem the build
should need SO much memory... Feel free to bump but it'd be even
better to figure out why it needs so much and
Perhaps because you named the news file "2020-04-dd-7-7-3-available.md» ? Not
sure. The staging site is down at the moment, so hard to cross-check…
Jan
> 14. mai 2020 kl. 04:18 skrev Noble Paul :
>
> I just finished all the steps given in
>
Oh good, thanks for posting ‘cause I thought I’d screwed one up. Looks like
it’s fixed now though?
> On May 14, 2020, at 1:33 AM, David Smiley wrote:
>
> FYI https://issues.apache.org/jira/browse/INFRA-20253
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
>
I've committed the file name change directly to prod . It's showing
the correct version now
thanks,
On Thu, May 14, 2020 at 7:28 PM Jan Høydahl wrote:
>
> Perhaps because you named the news file "2020-04-dd-7-7-3-available.md» ? Not
> sure. The staging site is down at the moment, so hard to
+1 (binding)
Kevin Risden
On Thu, May 14, 2020 at 12:17 PM Nicholas Knize wrote:
> +1 (binding)
>
> Nicholas Knize, Ph.D., GISP
> Geospatial Software Guy | Elasticsearch
> Apache Lucene PMC Member and Committer
> nkn...@apache.org
>
>
> On Thu, May 14, 2020 at 11:02 AM Namgyu Kim wrote:
>
+1
On Thu, 14 May 2020 at 22:42, Kevin Risden wrote:
> +1 (binding)
>
> Kevin Risden
>
>
>
> On Thu, May 14, 2020 at 12:17 PM Nicholas Knize wrote:
>
>> +1 (binding)
>>
>> Nicholas Knize, Ph.D., GISP
>> Geospatial Software Guy | Elasticsearch
>> Apache Lucene PMC Member and Committer
>>
+1
On Thu, May 14, 2020 at 10:33 PM Tommaso Teofili
wrote:
> +1 (binding)
>
> Tommaso
>
> On Tue, 12 May 2020 at 09:37, Dawid Weiss wrote:
>
>> Dear Lucene and Solr developers!
>>
>> According to an earlier [DISCUSS] thread on the dev list [2], I am
>> calling for a vote on the proposal to
+1 (binding)
Nicholas Knize, Ph.D., GISP
Geospatial Software Guy | Elasticsearch
Apache Lucene PMC Member and Committer
nkn...@apache.org
On Thu, May 14, 2020 at 11:02 AM Namgyu Kim wrote:
> +1
>
> On Thu, May 14, 2020 at 10:33 PM Tommaso Teofili <
> tommaso.teof...@gmail.com> wrote:
>
>>
Hello.
The discussion subject here has two parts i.e. "Lucene-Solr split" and "Solr
promoted to TLP" and I'd be curious what doing the former separately ahead of
the latter might look like and/or if consensus around that would be different?
Thinking aloud, as a hypothetical scenario like.
*
Perhaps a bit of a wildcard question or thought ... would any split out
top-level project necessarily be called "Apache Solr" or could the split out
project be called "Apache " with "Apache Solr" as its initial
sub-project and over time there may be other sub-projects added? No particular
name
Noble,
We're still missing a few:
https://cwiki.apache.org/confluence/display/LUCENE/ReleaseTodo#ReleaseTodo-UpdatetheprojectDOAPfiles
https://cwiki.apache.org/confluence/display/LUCENE/ReleaseTodo#ReleaseTodo-GenerateBackcompatIndexes
Also, the release is not on the mirrors -
20 matches
Mail list logo
