at all - you just want
to supress an individual email for each change if its going to be that many.
--
Mark Miller
about.me/markrmiller
On March 16, 2014 at 9:45:42 AM, David Smiley (@MITRE.org) ([hidden
email]/user/SendEmail.jtp?type=nodenode=4124847i=0) wrote:
Sorry for all the email spam last
I fixed this last night this morning.
Alexandre Rafalovitch wrote
I was doing some searching on issues and noticed 4.7 is listed in
Unreleased versions. Also, I have a couple of open issues that
(possibly due to my mistake) are marked as open but target at 4.7.
Was not sure if this is a
Sorry for all the email spam last night, folks.
I Released Lucene Solr 4.7 in JIRA last night. I updated the
instructions here
https://wiki.apache.org/lucene-java/ReleaseTodo#Update_JIRA to explicitly
indicate *not* to have JIRA bump the Fix-version values.
~ David
-
Author:
Jack Krupansky-2 wrote
And maybe there needs to be special formatting to highlight the importance
of Uncheck the box that says send an email for these changes.,
although
the omission of that step did highlight the main issue I mentioned.
My error was not neglecting to see that, it was
Woohoo! And thanks for all your hard work as R.M., Simon.
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/ANNOUNCE-Apache-Lucene-4-7-0-released-tp4119813p4119840.html
Sent from the Lucene -
+1 to both ideas: delete at the time we address a comment (rendering the
comment obsolete) and/or do so at release time if we neglected to delete a
comment earlier. It’s a low-priority thing any way.
But what about comments that don’t lead to an edit to the page? I’ve asked
about the
I was just thinking about the comments feature of the Solr Reference Guide
(e.g. Confluence). On one hand it's a nice feature that also allows
non-committers to be involved. But, over time, couldn't it easily get out
of hand (as-implemented)? That is... as a series of ever-growing comments
that
Nice!
And I see the infra ticket was fixed today.
Hopefully it will encourage more contributions. If someone can show an
example of this in action (not necessarily Lucene/Solr) it'd be nice to see.
Unfortunately, there's still a huge gap between an actual bona-fide GitHub
run project, and what
Awesome to have another committer, and in my neck of the woods too. Welcome!
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
Awesome; glad to have you Areek!
~ David
Areek Zillur wrote
Thanks Robert! I am very pleased to be a committer to Lucene/Solr!
I am originally from Dhaka, Bangladesh. I am currently a 4th year Computer
Engineering
student at University of Waterloo in Canada. I was fortunate enough to
have
Whoops; I thought I got the sha1's correctly; I'll try again.
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
Fixed. (Yes I do know about ant precommit... but long story never mind why
these problems happenned.)
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
+1, Mark.
Git isn't perfect; I sympathize with the annoyances pointed out by Rob et.
all. But I think we would be better off for it -- a net win considering the
upsides. In the end I'd love to track changes via branches (which includes
forks people make to add changes), not with attaching patch
Hi Karl!
I suggest that you put the point data you need in BinaryDocValues. That is
both the x y into the same byte[] chunk. I've done this for a Solr
integration in https://issues.apache.org/jira/browse/SOLR-5170
~ David
karl.wright-2 wrote
Hi All (and especially Robert),
Lucene
Nice investigation Mike! Your observation about it doing multiple block
decodes is one reason why I chose BinaryDocValues in SOLR-5170 to use one
byte[] for a pair of numbers. In Karl's last email he remarked this was still
only 20% faster than looking up a pair of NumericDocValues; I suspect
Welcome to the team Joel!
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Welcome-Joel-Bernstein-tp4093247p4093417.html
Sent from the Lucene - Java Developer mailing list archive at
Pradeep, you should actually comment in JIRA. Responding to JIRA emails
doesn't work (I think).
To answer your question, the fundamental capabilities in SOLR-2155 made it
into Solr 4. SOLR-2345 is specifically about using the geodist() function
query in addition to the more awkward method of
Erick,
Kranti referred to the *Confluence* wiki, in other words, the Solr Reference
Guide. Am I correct in that only committers can have write access to that?:
Welcome Cassandra! And thanks for sharing your background; it's nice to know
more about others in the community. I'm in the Boston area -- Lowell
specifically.
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
+1
Thanks Hoss, Cassandra, and to everyone else who contributed!
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/VOTE-RC2-Release-apache-solr-ref-guide-4-4-pdf-tp4080395p4080488.html
Sent
Oh; I should have read more carefully. Thanks!
~ David
sarowe wrote
David, you made your edits after Hoss called the RC1 vote - I was arguing
for an RC2 based partly on your changes.
Steve
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View
Darn; I haven't noticed these failures. I'll investigate. I need to set up
some sort of email filter alert system so they come to my attention
immediately.
(without knowing what the bug is; it's most likely in the complicated test).
~ David
Policeman Jenkins Server-2 wrote
Build:
Welcome Han Jiang!
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Welcome-Han-Jiang-as-a-new-Lucene-Solr-committer-tp4069013p4069120.html
Sent from the Lucene - Java Developer
Hi Kranti,
I think this post belongs on the solr-user list. Any way, Solr join queries
don't score. Filter queries don't score either so even if join queries did,
using them in a filter query wouldn't help. For what it's worth, I
implemented a Solr scoring join query for a customer by basing
Interesting. But the sysout-over-slf4j project declares:
The sysout-over-slf4j module is explicitly not intended to encourage the
use of System.out or System.err for logging purposes. There is a
significant performance overhead attached to its use, and as such it
should be considered a
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Numeric-Multi-Valued-Doc-Values-tp4065423p4066189.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
That's a schema issue. Lucene doesn't really have one so there isn't a
definitive answer there. For Solr, this ideally should be cleaner but it
isn't, last I checked a month ago. You could poke around the TrieField code
but in the end you will probably end up making assumptions on your code
Hi Ahmed,
I faced your conundrum with JTS early last year. As you know, the Apache
Software Foundation doesn't like it's projects depending on GPL and even
LGPL licensed libraries. The ASF does not have clear unambiguous language
on how its projects can depend on them in a limited sense.
I feel the same as Shawn; I was quite skeptical until the reasons were
finally given. And I agree that the war file distribution needs to stick
around longer. That's a big deal from a user perspective; not something to
happen in a point release. To be clear, I think a change like this should
Please add me to both wikis, userid: DavidSmiley
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/ANNOUNCE-Solr-wiki-editing-change-tp4050968p4055736.html
Sent from the Lucene - Java Developer
Thanks for that tip Dawid. I'll consider AspectJ some day; that's an
interesting approach.
So as it turns out, I was wrong when I said that the same shapes etc. were
being tested when I switched the directory via the system property. I
thought I checked for that but apparently I got confused.
Welcome Shalin!
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Welcome-Shalin-Shekhar-Mangar-to-the-PMC-tp4053885p4054240.html
Sent from the Lucene - Java Developer mailing list archive at
I've been reworking a randomized test in Lucene spatial; it's pretty hard.
One particular failing test is driving me crazy right now. I figured out
that the problem would only occur if the RAMDirectory was chosen, and of
course if I created just the right sequence of indexed shapes and query for
to put a // nocommit there too
;)
Mike McCandless
http://blog.mikemccandless.com
On Sat, Apr 6, 2013 at 2:09 PM, David Smiley (@MITRE.org)
lt;
DSMILEY@
gt; wrote:
I've been reworking a randomized test in Lucene spatial; it's pretty
hard.
One particular failing test is driving me
I'll try to make a version of the test that is unrandomized -- I'll index the
exact shapes needed and query for the specific shape using the right
algorithm. And at that point, I'll try and reduce it. Simon's right; I'm
looking for debugging tips/strategy advise. I find it pretty odd that my
Interesting conversation. So if hypothetically Solr's FileFloatSource /
ExternalFileField didn't yet exist and we were instead talking about how to
implement such a thing on the latest 4.x code, then how basically might it
work? I can see how to implement a Solr CodecFactory ( a SchemaAware one)
That would be nice! There is similar machinery in Solr's ExternalFileField.
In the spatial module I'd like to cache data per-segment; it's current cache
sucks to say the least. My current plans are to use BinaryDocValues so I
might not use this proposed machinery after-all but nonetheless I
Congrats Stefan! And terrific work on Solr's admin UI -- its both useful and
a pleasure to use.
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
If 120 is the new maximum, is it also the generally recommended
reflow/line-break for javadocs? Or should that be 100, or stay at 80? I
suggest 100.
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
Thanks for the FYI!
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Faster-GitHub-mirroring-tp4029346p4029356.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
I agree; it should return an error instead of mislead/confuse the user.
~ David
Jack Krupansky-2 wrote
I don’t get any error or any effect from this curl command:
curl http://localhost:8983/solr/update?commit=true --data-binary '
delete
query
sku:td-01
/query
/delete
'
But, if I add
Shai Erera wrote
Yonik, unlike Solr facets (which manage everything in the search index),
the Lucene module comes with a sidecar taxonomy index, so e.g. when Solr
replicates shards, it will need to replicate one other index files. That's
the big difference, the rest are miniscule I think. And
Those are good points Yonik. I guess I don't know what to think anymore.
Yonik Seeley-4 wrote
On Thu, Nov 29, 2012 at 1:24 AM, David Smiley (@MITRE.org)
lt;
DSMILEY@
gt; wrote:
Maybe we should have a
roster somewhere of parts of the codebase that have an owner.
Taking ownership
: David Smiley (@MITRE.org)
Sent: Tuesday, November 27, 2012 11:43 PM
To: [hidden email]UrlBlockedError.aspx
Subject: dismax vs edismax
It was my hope that by now, the dismax edismax distinction would be a
thing
of the past, such that we'd simply call this by one name, simply dismax.
From memories
Robert Muir wrote
You generally have many transients and an active smaller core. I think
this is not at all uncommon.
I think it significantly helps when we have committers that unofficially
take ownership over certain areas, for lack of a better word. Just
meaning they look out for it and
It was my hope that by now, the dismax edismax distinction would be a thing
of the past, such that we'd simply call this by one name, simply dismax.
From memories of various JIRA commentary, Jan wants this too and made great
progress enhancing edismax, but Hoss pushed back on edismax overtaking
ant precommit will check if the source tree is dirty (i.e. contains files
not in source control) and stop with a failure if so. I find that rather
annoying since I've usually got a variety of .patch files and IDE config
changes. What is the rationale behind this check? How do people usually
://blog.mikemccandless.comhttp://blog.mikemccandless.com/
On Mon, Nov 26, 2012 at 9:46 AM, David Smiley (@MITRE.org)
[hidden email]x-msg://149/user/SendEmail.jtp?type=nodenode=4022419i=1
wrote:
ant precommit will check if the source tree is dirty (i.e. contains
files
not in source control) and stop
modified files case? And the
fact that svn:ignore=* doesn't cover this case? If so, okay, that makes sense.
If not, can you increase your word count a little and help me understand?
Steve
On Nov 26, 2012, at 2:25 PM, David Smiley (@MITRE.org) [hidden
email]x-msg://155/user/SendEmail.jtp?type
Mark,
Do I need to do anything for the bot to make its comment, aside from the
commit? I just made a commit to both branches. How much delay is there /
i.e. what's its schedule?
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in
Hi Dawid.
There's an ant build file that looks for Test*, *Test, and EXCLUDES '$'
hence no inner class.
I wish the test infrastructure simply scanned all test classes in test paths
for @Test or JUnit Testcase subclass. After all, the vast majority of
classes in /test/** are going to be tests. No
Hi Adrien.
I've been vaguely following LUCENE-4547. Wether or not there is official
multi-valued support in DocValues, my question pertains to my ability to
customize a particular in-memory format to my liking. I'd like to know
what's involved. I'm trying to address variable values per
Based on an IM chat with Simon, it appears that doing a custom DocValues
Source subclass is ultimately more work than developing my own custom cache
per-segment, initializing the initial data out of DV on-disk. The challenge
(for me) is to figure out how to do that. I'll look at FieldCache DV
Nice Jan. Couple comments:
1.
You put documents in it (called indexing) via XML, JSON or binary over
HTTP.
The reference to binary in this way is odd, and likewise for the sentence
that follows it. Perhaps:
You put documents in it (called indexing) by sending them over HTTP in
either an XML
I'm working with Lucene 4's DocValues in a Solr app, but using it to store
multiple values encoded into a byte array. Unfortunately, Solr's
DocumentBuilder code passes each value individually to the FieldType calling
createField() for each value, and so the FieldType never sees all the values
for
Simon,
Your response confuses me.
3. pull into trunk only from upstream
Do you mean a local branch trunk, and coming from apache?
... and push to github
What; you can push to github's mirror? I thought it was read-only?
And do you mind telling me/us how you take a change you commit to trunk
+1 Cool.
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Commit-tags-in-JIRA-tp4019500p4019518.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
+1 I'm definitely in favor of moving to git. I've gotten past the learning
curve hurdle and I appreciate its benefits.
The real challenge, I think, is figuring out how we can get real
collaboration like what is possible on GitHub, without actually truly being
on GitHub. Maybe Atlassian's new
Welcome Alan! You've been improving challenging parts of Lucene.
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
Does this mean a re-spin?
I have a low-risk but high impact (in terms of features) bug-fix I would
like to get in to 4.0: https://issues.apache.org/jira/browse/LUCENE-
but I did not want to put the breaks on any release that was being voted on.
~ David
-
Author:
I just got it committed to the 4.0 release branch, after I ran tests.
I didn't add a CHANGES.txt entry because this is basically a bug to an
existing entry that is already post-beta (SOLR-3304).
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View
Wow; that looks like a serious issue to me.
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/VOTE-release-4-0-tp4009770p4009941.html
Sent from the Lucene - Java Developer mailing list archive
Hi Jack,
Thanks for your interest. Each SpatialStrategy has its pros and cons. I'm
working through creating slides for a conference today in fact:
http://www.basistech.com/search-conference/presentations/ Now that the
Solr adapters are committed, I'll be focusing more on documentation. That
Hi Rob.
I think it's fairly critical that at least some of the Solr spatial adapters
get committed SOLR-3304. I've been working on it and related issues like
LUCENE-4208.
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
Hi Jacek,
This strikes me as a project that would exist separate to Solr because it
would have little to do with it. In federated search, you are searching
multiple search platforms of ideally any flavor. Why base the federated
search platform on any one of these (e.g. Solr)? I think there is
Can you please remind us on the ramifications of a beta release for us
developers? In particular, I mean are there limitations on the sorts of
changes? The alpha introduced no index change, for example. Sorry if
you've answered this before but I had trouble looking for it.
Cheers,
~ David
Thank you Robert!
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/JENKINS-Lucene-Solr-4-x-Windows-Java6-64-Build-419-Failure-tp3996835p3996843.html
Sent from the Lucene - Java Developer
Ok. I'll just go ahead and move it, and change to inclusive edge. If you
want to add features like that then go for it. Mostly I felt the class
needed a better home.
~ David
Martijn v Groningen-2 wrote
+1 Good idea. I think that there also should be other implementations
for the
It turns out Solr has a ValueSourceRangeFilter that I think should be ported
over. I'll create an issue:
https://issues.apache.org/jira/browse/LUCENE-4251
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
FYI I fixed this javadoc warning in recent commits.
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/JENKINS-Lucene-Solr-trunk-Linux-Java6-64-Build-1078-Failure-tp3991771p3991951.html
Sent from
Welcome Greg! Merry committing.
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Welcome-Greg-Bowyer-tp3990688p3990872.html
Sent from the Lucene - Java Developer mailing list archive at
-1 to remove all via
I agree with the opinions expressed in detail by Mark and Eric. But I don't
think a committer should feel obliged to add their name if their involvement
seemed particularly light in their opinion.
~ David
-
Author:
Nagendra,
Simply open a JIRA issue and attach a patch. Lucene/Solr development
largely centers around JIRA issues via the comments.
Ideally you should provide tests as part of your patch; it certainly won't
be committed if sufficient tests are never furnished. If your NRT
implementation really
And for those that are curious, the difference between the valid jar (as
identified by the checksum sha1 in Solr) and the one I had with a different
checksum, is that the bad one was built ~40 seconds earlier, as reflected
in a comment date in
I noticed that Solr's README.txt says to use Ant 1.7 and explicitly NOT Ant
1.8:
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/README.txt
Is it because of this?:
http://lucene.472066.n3.nabble.com/test-output-is-sometimes-truncated-td3893614.html
In any case, I think the README should
+1 absolutely. I'm not a fan of binaries in source control when it can be
avoided, and ivy (and maven) help.
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
+1 on removal of the old UI from trunk
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Remove-old-Solr-UI-from-trunk-tp3802540p3804136.html
Sent from the Lucene - Java Developer mailing list
Welcome Stefan.
I'm glad we have someone we can assign to Solr's UI, and perhaps you can
assist on the Lucene's website. Hmmm, even the /browse UI too -- plenty
to work on :-) Hey, just curious, have you tried AJAX-Solr? I've been
using it a lot lately and I'm curious as to your reaction.
~
Cool; pull-requests via GitHub. Has anyone reacted to one of these messages
and applied the change before? If so what was the process? Since
lucene-solr is a mirror, is it impossible?
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this
a patch in JIRA and click the check box about donating. They seem to find that
important, and you don't have the same mechanism when grabbing pull requests
from github.
On Feb 20, 2012, at 10:56 AM, David Smiley (@MITRE.org) wrote:
Cool; pull-requests via GitHub. Has anyone reacted to one
A belated welcome! (I'm new too)
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Welcome-James-Dyer-tp3732469p3749495.html
Sent from the Lucene - Java Developer mailing list archive at
Grant; did you miss my JIRA issue to add the book info?
https://issues.apache.org/jira/browse/SOLR-3096
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
Wow! It is truly an honor to be selected by the Lucene PMC to join the
committer ranks. You are a top notch team of coders working on one of the
most important open-source projects.
About me:
My technical background is all tiers of web development with a focus on the
middle tier and Java. Of
The new site looks awesome! Thanks so much for your efforts, Grant.
I see you didn't get a chance to incorporate the 3 Packt books to the Solr
site. These need to be featured on Solr's front page for the ASF to collect
a cut of the book sales. I'm willing to help with this aspect of the
Congrats Erick! I've noticed you on the mailing list for a long time and
you've offered many people good advise.
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context:
You're right; it shouldn't be shoved in at the last second -- I didn't mean
to imply that. It should be committed and then we'll give it a comfortable
amount of time. When that time is up, and if v3.2 waits for it, then 3.2
will probably be at about the 3-month mark since the last release -- in
The basis of my preference to start the 3.2 release was the existence of some
cool meaningful feature in it over the previous release. Since Result
Grouping isn't going to make it, I am not in favor of releasing 3.2. Why not
wait till we're happy with it being committed? I've toyed with it a
Cool idea! I had the same thought -- an automated reminder every 2.5 months
or so.
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/VOTE-Release-Lucene-Solr-3-2-0-tp2993434p2997954.html
Sent from
Clearly a year+ is too long to release, and thankfully it appears that's in
the past for Lucene/Solr. But on the other extreme, one can release too
quickly as well, of course. There is overhead to performing the release
itself. Consequently there should be enough goodness in the release to
make
Michael McCandless-2 wrote:
I think a more productive area of exploration (to reduce RAM usage)
would be to make a StringFieldComparator that doesn't need full access
to all terms data, ie, operates per segment yet only does a few ord
lookups when merging the results across segments. If
Wow, 17 replies to my email overnight! This is clearly an interesting topic
to folks.
Hi Dawid.
Sadly, I won't be at Lucene Revolution next week. That's where all the cool
kids will be; I'll be home and be square. I made it to O'Reilly Strata in
February (a great conference) and I'll be
I've been pondering how to reduce the size of FieldCache entries when there
are a large number of Strings. I'd like to facet on such a field with Solr
but with less memory. As I understand it, FSTs are a highly compressed
representation of a set of Strings (among other possibilities). The
. There are very few of these
two worry about. Those without a resolution status should probably just be
assigned to 3.2 -- so yes I agree that's what we should do. Then Next can
be deleted.
~ David Smiley
Michael McCandless-2 wrote:
On Fri, Apr 29, 2011 at 12:12 AM, David Smiley (@MITRE.org
(Comments on SOLR-2191 between Mark I were starting to get off-topic with
respect to the issue so I am continuing the conversation here)
A lot of JIRA issues seem to fall off the radar, IMO. I'm talking about
issues that have patches and are basically ready to go. There are multiple
ways to
It's good to see this discussion finally happen. Some things are in Solr
(e.g. faceting, function queries, Yonik's recent join patch, ...) that
probably belong in Lucene. As someone contributing functionality to
Lucene/Solr in SOLR-2155 (Geospatial search via geohash prefix techniques),
So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in
yesterday (apparently it didn't)? :-( Darn... maybe I shouldn't have waited
for a committer to agree with the issue. I would have had it in Saturday.
~ David Smiley
-
Author:
I don't want to overstep my role in this conversation (not being a committer
as much as I want to be), but shouldn't there be some thought about what we
should *add* to 3.x before 3.x gets rushed out the door? I have no doubt 3.x
will be stable; I didn't mean rushed in that sense. I'm sure we
Chris Hostetter-3 wrote:
CharFilters and TokenFilters have different purposes though...
http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#When_To_use_a_CharFilter_vs_a_TokenFilter
(ie: If you use MappingCharFilter, you can't then tokenize on some of the
characters you
Robert Muir wrote:
On Tue, Feb 8, 2011 at 9:12 AM, David Smiley (@MITRE.org)
dsmi...@mitre.org wrote:
I'm skeptical that whatever the difference is is relevant in the scheme
of
things. The cost to keeping it is introducing confusion on users, and
more
code to maintain.
its pretty
ISOLatin1AccentFilter is deprecated, presumably because you can (and should)
use MappingCharFilter configured with mapping-ISOLatin1Accent.txt. By that
same reasoning, shouldn't ASCIIFoldingFilter be deprecated in favor of using
mapping-FoldToASCII.txt ?
~ David Smiley
-
Author:
1 - 100 of 120 matches
Mail list logo
