If Marcus has ability to edit existing pages, why don't we create the empty
page for him and sort out access granting issues later. I'd hate for this
much needed SIP to bog down on a technical issue.
-Gus
On Mon, Apr 20, 2020 at 7:10 AM Jan Høydahl wrote:
> Please retry. I gave edit access to
What Alan says makes sense to me -- simple and sufficiently addresses the
pain point Adrien raises. I don't think we need a long class name which is
also some extra class in addition to the current one (confusing); I'd
prefer one simple numeric class name (per int/long/float/double) with a
SIP here:
https://cwiki.apache.org/confluence/display/SOLR/Updated+Solr+Admin+UI
On Mon, Apr 20, 2020 at 9:32 AM Gus Heck wrote:
> If Marcus has ability to edit existing pages, why don't we create the
> empty page for him and sort out access granting issues later. I'd hate for
> this much
: I would like to try and address the issue of switching from http to https as
referenced
: in https://issues.apache.org/jira/browse/SOLR-12182
I would suggest asking these questions (both about hte validity of
the patch file, and about possible work arounds) directly in the jira you
Please retry. I gave edit access to confluence user id ‘marcussorealheis’.
Jan
> 20. apr. 2020 kl. 01:30 skrev Marcus Eagan :
>
> I do need help. I am not allowed to create a SIP. Or, I have been unable to
> create a SIP in three previous attempts.
>
> Marcus
>
> On Sun, Apr 19, 2020 at 3:45
Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0 had 78 failures
Week: 1 had 117 failures
Week: 2 had 99 failures
Week: 3 had 69 failures
Failures in Hoss' reports for the last 4 rollups.
There were 243 unannotated tests that failed in
Hello,
Lucene currently doesn't require consistency across data-structures. For
instance it is possible to have different values in points and doc values
under the same field name. Until now, we worked around it either by making
features use a single data-structure, e.g. facets only use doc
One way of doing this might be to add an additional field type that adds both
point and docvalues, and then have factory methods for queries and sorts on the
field type. So for example a LongPointAndValue field would automatically index
its value into both BKD and NumericDocValues, and then
Could we use this as a stepping stone towards a schema? Just a very
lightweight schema that only enforces what we can easily enforce
today, but put some minimal abstraction in place where we can hang
future consistency checks.
Re: value consistency; could we do a best-effort enforcement in
Hello,
I am new to the lucene-solr code base and I am attempting to learn how things work.Are there any guides/diagrams/documents anywhere to help people get orientated?
Many thanks
Martin Entwistle
Software Developer
IBM SecurityUnless stated otherwise above:
IBM United Kingdom Limited -
10 matches
Mail list logo
