Hi Harley,
See: http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4
In SOLR-2155 you had to explicitly specify the prefix encoding length,
whereas in Solr 4 you specify how much precision you need and it figures out
what the length is that satisfies that. When you first use the field, it'll
Hmm; weird. It looks right. Does it work without the sort? -- i.e. does the
filter work? Are there more interesting looking error messages output by
Solr?
Rakudten wrote
Hello!
I´m trying to sort by geodist() distance, but it seems that I can´t:
*The query:*
Strange. The code in Solr that has that error string passes an an additional
exception that will have its own error message that is more detailed, and
you'll see that in the stack trace in the Solr logs; perhaps in your error
response too but I'm not sure.
If you remove the sorting, are the
Pires, Guilherme wrote
Hello David,
Thanks for your response.
I'm working deeply in this and it's fully decided that solr 4.1 + JTS is
going to be supporting the map navigation for a 'public facing' GIS
solution, i.e. will deliver the objects return by a bounding box
intersection.
Javier Molina wrote
This very wide rectangle will cause an OutOfMemoryError
-180 3 180 3.016668
While this one, slightly taller will work fine.
-180 3 180 3.5
Due to the bug, the accuracy computing algorithm believes the width for both
of these is 0. That algorithm also looks
I'm glad to be of help.
This is all possible using Solr 4 without programatic customization. As
always remember the docs:
http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4#IndexingThat
has an example of index a circle. Not much to it.
The only aspect of the
Hi Stefano.
I answered someone's question on stackoverflow which is basically the same
question you have:
http://stackoverflow.com/questions/13723891/lucene-4-0-spatial-calculate-max-distance-dynamically-using-indexed-documets/13764793#13764793
Essentially, you should index circles and then
Javier,
Your minX is slightly greater than maxX, which is interpreted as a line that
wraps nearly the entire globe. Is that what you intended?
If this is what you intended, then you got bitten by this unfixed bug:
https://issues.apache.org/jira/browse/LUCENE-4550
As a work-around, you could
What good is a key-value store in the context of oakstream's question?
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
) on a field?
With regards to search, will an Intersects function behaviour will be OR,
that is match any rectangle in my example on that multivalued field that
intersects with the given area?
Thanks,
Javier
On 22 January 2013 05:43, David Smiley (@MITRE.org) lt;
DSMILEY@
gt
enlighten me!
~ David Smiley
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Using-Solr-Spatial-in-conjunction-with-HBASE-Hadoop-tp4034307p4034806.html
Sent from the Solr - User mailing list
with Otis's
advise.
~ David Smiley
oakstream wrote
Hello,
I have point data (lat/lon) stored in hbase/hadoop and would like to query
the data spatially with polygons. (If I pass in a few polygons find me
all the records that exist within these polygons. I need it to support
polygons not just box
Mladen,
FYI I just committed this to 4.x:
https://issues.apache.org/jira/browse/SOLR-4230
~ David
mladen micevic wrote
Hi,
I went through example for spatial search in Solr 4.0
(http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4)
Both indexing and searching work fine.
Example
It's unusual to have Solr be the first point of entry into a service.
Usually it's fronted with a web application that has the business logic that
knows how to map the request to the search back-end.
Given your further questions, almost anything could work without much
trouble:
* A standard
Hi Mladen,
Despite some similarities at first glance, the Solr 4 spatial fields are not
implemented with Solr query parsers, unlike Solr 3 spatial. Everything in
quotes is handled by the field type. What you're looking for is for the
Solr 3 geospatial functions to be adapted to support the Solr
britske wrote
Ah; ok. But still, my first suggestion is still what I think you could
do
except that the algorithm is simpler -- return the first matching 'y' in
the
document where the point matches the query. Alternatively, if you're
confident the number of matching documents (hotels) is
The indexed=true side is quite efficient. The stored=true side -- not so
much, but the strings you have here are pretty small and I wouldn't worry
about it. Solr 4.1 (unreleased) does a great job here and compresses all
the stored field data across documents.
~ David
Jie Sun wrote
Hi -
our
Hi Britske,
This is a very interesting question!
britske wrote
...
I realize the new spatial-stuff in Solr 4 is no magic bullet, but I'm
wondering if I could model multiple prices per day as multipoints,
whereas:
- date*duration*nr of persons*roomtype is modeled as point.x
britske wrote
Hi David,
Yeah interesting (as well as problematic as far is implementing) use-case
indeed :)
1. You mention there are no special caches / memory requirements inherent
in this.. For a given user-query this would mean all hotels would have to
seach for all point.x each time
:35, David Smiley (@MITRE.org) [via Lucene]
[hidden email]UrlBlockedError.aspx wrote:
britske wrote
That's seriously awesome!
Some change in the query though:
You described: To query for a business that is open during at least some
part of a given time duration
I want To query
it , which im sure you can tell :)
Thanks a lot David,
Cheers,
Geert-Jan
Sent from my iPhone
On 9 dec. 2012, at 05:35, David Smiley (@MITRE.org) [via Lucene]
[hidden email]UrlBlockedError.aspx wrote:
britske wrote
That's seriously awesome!
Some change in the query
Javi,
The center point of your query circle and the indexed point is just under
49.9km (just under your query radius); this is why it matched. I plugged in
your numbers here:
http://www.movable-type.co.uk/scripts/latlong.html
Perhaps you are misled by the projection you are using to view the
as in many cases
the problem is somewhere else where you would never imagine.
Thanks for the hint.
Cheers,
Javier
On 11 December 2012 02:47, David Smiley (@MITRE.org) lt;
DSMILEY@
gt;wrote:
Javi,
The center point of your query circle and the indexed point is just
under
49.9km
Hello again Geert-Jan!
What you're trying to do is indeed possible with Solr 4 out of the box.
Other terminology people use for this is multi-value time duration. This
creative solution is a pure application of spatial without the geospatial
notion -- we're not using an earth or other sphere
this functionality.
~ David
britske wrote
Again, this looks good!
Geert-Jan
2012/12/8 David Smiley (@MITRE.org) [via Lucene]
ml-node+s472066n4025359h19@.nabble
Hello again Geert-Jan!
What you're trying to do is indeed possible with Solr 4 out of the box.
Other terminology people use
calculation even without
solr.SpatialRecursivePrefixTreeFieldType field type usage.
WBR Viacheslav.
On 26.11.2012, at 18:52, David Smiley (@MITRE.org) wrote:
Hi Viacheslav,
1. You don't need JTS unless you're using polygons or WKT and your examples
uses neither. So you can remove
Hi Viacheslav,
1. You don't need JTS unless you're using polygons or WKT and your examples
uses neither. So you can remove the spatialContext attribute to use the
default, and remove the JTS jar. But that shouldn't be related to your
reported problem.
2. The units for d= in the circle are in
The particular JavaScript I referred to is this:
function processAdd(cmd) {
doc = cmd.solrDoc; // org.apache.solr.common.SolrInputDocument
lat = doc.getFieldValue(LATITUDE);
lon = doc.getFieldValue(LONGITUDE);
if (lat != null lon != null)
doc.setField(latLon, lat+,+lon);
}
Mark Miller-3 wrote
I'm talking about an update request. So if you make an update, when it
returns, your next search will see the update, because it will be on
all replicas.
I presume this is only the case if (of course) the client also sent a
commit. So you're saying the commit call will not
Oh I'm sorry, I should have read your question more clearly. I totally
forgot that solr.PointType supports a configurable number of dimensions. If
you need more than 2 dimensions as your example shows you do, then you'll
have to resort to indexing your spatial data in another Solr core as
Borja,
Umm, I'm quite confused with the use-case you present.
~ David
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/PointType-multivalued-query-tp4020445p4020609.html
Sent from the Solr -
Sorry, you're out of luck. SRPT could be generalized but that's a bit of
work. The trickiest part I think would be writing a multi-dimensional
SpatialPrefixTree impl.
If the # of discrete values at each dimension is pretty small (100? ish?),
then there is a way using term positions and span
the choices available. I'd love to
see one.
~ David Smiley
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/BM25-model-for-solr-4-tp4020400p4020411.html
Sent from the Solr - User mailing list
for it on another
machine.
~ David Smiley
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-4-0-Spatial-Search-schema-xml-and-data-config-xml-tp4020376p4020413.html
Sent from the Solr - User mailing
That'll probably work. Or with Solr 4's new spatial field types you can do a
rectangle query of the whole world: geofieldname:[-90,-180 TO 90,180].
Perhaps it'd be nice to add explicit support for [* TO *].
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
Nice!
On Oct 17, 2012, at 10:50 AM, Eric Khoury [via Lucene] wrote:
I'm using the X axis for time availability start and end (total minutes since
Jan 2012), each asset can have multiple rectangles (multiple avail start and
end). My original design had a bounding rect of 20 years (0 -
Eric,
Can you please elaborate on your workaround? I'm not sure I get your drift.
~ David
On Oct 16, 2012, at 12:54 PM, Eric Khoury [via Lucene] wrote:
Thanks for the help David, makes sense. I found a workaround, creating much
smaller rectangles and updating them more often.Glad to have
Hi Ere,
You are using it correctly. The problem is this:
https://issues.apache.org/jira/browse/LUCENE-
Sadly, this just missed the 4.0 release which appears to be imminent. If
the release needs to be respun then I'll get this simple fix in it. Yeah
this sucks and it's very frustrating to
http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4
Definitely needs some updating; I will try to get to that this weekend.
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
For your use-case of time ranges, set geo=false (as you've done). At this
point you have a quad tree but it doesn't (yet) work properly for the default
min max numbers that a double can store, so you need to specify the boundary
rectangle explicitly and to the particular numbers for your
If you can stick to two dimensions then great. Remember to set the boundary
attribute on the field type as I described so that spatial knows the
numerical boundaries that all the data must fit in. e.g. boundary=0 0
10 2.5 (substituting whatever appropriate number of time units you need
for
When I said boundary I meant worldBounds.
Oh, and set distErrPct=0 to get precise shapes; the default is non-zero.
It'll use more disk space of course, and all the more reason to carefully
choose your world bounds carefully.
-
Author:
Yes absolutely. Since 4.0 hasn't been released, anything with a fix version to
4.0 basically implies trunk as well. Also notice my comment Committed to
trunk 4x which is explicit.
~ David
On Sep 17, 2012, at 12:02 PM, Eric Khoury [via Lucene] wrote:
Hi David, I see that you committed the
Solr 4 is certainly the goal. There's a bit of a setback at the moment until
some of the Lucene spatial API is re-thought. I'm working heavily on such
things this week.
~ David
On Aug 28, 2012, at 6:22 PM, Eric Khoury [via Lucene] wrote:
David, Solr support for this will come in Solr-3304 I
The solr.GeoHashFieldType is useless; I'd like to see it deprecated then
removed. You'll need to go with unreleased code and apply patches or wait till
Solr 4.
~ David
On Aug 29, 2012, at 10:53 AM, Eric Khoury [via Lucene] wrote:
Awesome, thanks David. In the meantime, could I potentially
You would index rectangles of 0 height but that have a left edge 'x' of the
start time and a right edge 'x' of your end time. You can index a variable
number of these per Solr document and then query by either a point or
another rectangle to find documents which intersect your query shape. It
Hey solr-user, are you by chance indexing LineStrings? That is something I
never tried with this spatial index. Depending on which iteration of LSP
you are using, I figure you'd either end up indexing a vast number of points
along the line which would be slow to index and make the index quite
that this technology is on its way into Solr 4, albeit not
quite yet.
Cheers,
~ David Smiley
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Tuning-caching-of-geofilt-queries-tp3998975p4000525.html
Sent
Yeah it is... I rather like this write-up:
https://sites.google.com/site/trescopter/Home/concepts/required-precision-for-gps-calculations#TOC-Precision-of-Float-and-Double
-- which also arrives at 2.37m worse case.
Aside from RAM savings, I wonder if there is any noticeable performance
Is there any documentation on the updateLog transaction log feature in Solr
4?
I started a quick prototype using Solr 4 alpha with a fairly structured
schema; no big text. I disabled auto-commit which came pre-enabled and
there's no soft-commit either. With CURL I posted a 1.8GB CSV file.
solr-user wrote
Thanks David. No worries about the delay; am always happy and
appreciative when someone responds.
I don't understand what you mean by All center points get cached into
memory upon first use in a score in question 2 about the Java OOM errors
I am seeing.
The underlying
On Aug 9, 2012, at 4:16 PM, solr-user [via Lucene] wrote:
I didn't know how the cache got triggered and the needScore=false now allows
some of my problem queries to finally work, and well within 2gb of mem.
needScore is an unfortunate hack in the Solr adapter to the Lucene spatial
module to
:
https://issues.apache.org/jira/browse/SOLR-3304
~ David Smiley
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/question-s-re-lucene-spatial-toolkit-aka-LSP-aka-spatial4j-tp3997757p424.html
samabhiK wrote
David,
Thanks for such a detailed response. The data volume I mentioned is the
total set of records we have - but we would never ever need to search the
entire base in one query; we would divide the data by region or zip code.
So, in that case I assume that for a single
Thinking more about this, the way to get a Lucene based system to scale to
the maximum extent possible for geospatial queries would be to get a
geospatial query to be satisfied by just one (usually) Lucene index segment.
It would take quite a bit of customization and work to make this happen. I
shines in its
ability to scale out if you have the resources to do it.
~ David Smiley
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-Spatial-Search-for-Specif-Areas-on-Map
Hi mcb
You're looking for spatial clustering. I answered this question yesterday
on Stack Overflow:
http://stackoverflow.com/a/11321723/92186
~ David Smiley
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066
Ugo,
I suggest simply manually filtering out red from the facet.prefix results
you get back. Not ideal, but it's easy and your problem seems like an
infrequent event and a minor nuisance.
~ David Smiley
p.s. thanks for buying my book
-
Author: http://www.packtpub.com/apache-solr-3
Yes, I definitely think so. At a minimum, I expect there will at least be a
patch or built jar file for you to get going by 1 June.
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
Mathias,
For what it's worth, someone using LSP (Lucene Spatial Playground)'s
RecursivePrefixTreeFieldType (which uses geohash encoding by default) quoted
a 2x performance increase over Solr's built-in LatLonType. To boost the
performance further, there are a couple parameters you can tweak.
Hi Marian. I'm the author of Solr2155.
SpatialQueryable is an interface provided by Solr. Where did you put the
SOLR-2155 built jar file? Perhaps you put it where it doesn't belong like
in your servlet engine's lib directory (varies). You can put this in a
variety of places like embedding it
See
https://issues.apache.org/jira/browse/SOLR-2155?focusedCommentId=13114839page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13114839
with my response following Geert-Jan's question.
~ David
-
Author:
used to great success with AJAX-Solr in place of AJAX-Solr's Theme junk.
Sorry if this turned into an AJAX-Solr advertisement but it is my opinion
that adopting AJAX-Solr for the role /browse has is ultimately a better
thing than a Velocity/JSP/PHP/ASP page based UI.
~ David Smiley
-
Author
In case anyone is curious, I responded to him with a solution using either
SOLR-2155 (Geohash prefix query filter) or LSP:
https://issues.apache.org/jira/browse/SOLR-2155?focusedCommentId=13115244#comment-13115244
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search
solrQuery.setQuery(*:*);
solrQuery.addFilterQuery({!func}geodist());
solrQuery.set(sfield, store);
solrQuery.set(pt, lat + , + lon);
solrQuery.set(sort, geodist() asc);
//disclaimer: I haven't run this
-
Author:
with shingling. Then at search time I used Span
queries and their unique ability to positionally query over more than one
field. There were some edge conditions that were tricky to debug when I had
a null value, but it was at least fixable with a sentinal value kluge.
~ David Smiley
-
Author: https
That's a fantastic answer, Shawn.
To more directly answer Bernd's question: Bernard, shard your data once
you've done reasonable performance optimizations to your single core index
setup (see Chapter 9 of my book) and the query response time isn't meeting
your requirements in spite of this. Solr
.
The Join support works across cores. See the wiki and associated JIRA issue
for it.
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Matching-queries-on-a-per-element-basis
performance improvements tied to flex that haven't seen the
light of day in an official release. It's a shame, really. So it's been so
long that, well, after it dawns on everyone that it that the code is 3
friggin years old without a release -- it's time to get on with the show.
~ David Smiley
Jamie,
You are using the field named point which is based on PointFieldType.
Keep in mind that just because this field type is named this way, does *not*
mean at all that other fields don't hold points, or that this one is
especially suited to it. Arguably this one is named poorly. This field
solrQuery.setParam(name,value).
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Spatial-search-with-SolrJ-3-1-How-to-tp2961136p3158134.html
Sent from the Solr - User mailing list
should move this. Yes? I really liked the idea of naming this Solr
Ecosystem but I admit that when it comes down to it, it's basically about
integrating with Solr.
Any thoughts on this from anyone?
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
Hi.
By the way, your uses of parenthesis are completely superfluous.
You can't just plop that {! syntax anywhere you please, it only works at
the beginning of a query to establish the query parser for the rest of the
string and/or to set local-params. There is a sub-query hacky syntax:
... AND
it. I have other priorities first.
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/intersecting-map-extent-with-solr-spatial-documents-tp3104098p3114922.html
Sent from the Solr - User
to be evaluated on every document matching
the keyword search. That will probably perform okay; not so sure for large
indexes with a *:* query.
Again, nice job. Could you please share an example of your ranking query?
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise
hope to add better support for this problem to Solr by the end of
the year.
Good luck.
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Pattern-Is-there-a-method-of-resolving
I see no reason why it would not be compatible.
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/KStemmer-for-Solr-3-x-tp2796594p2798213.html
Sent from the Solr - User mailing list archive at
external spatial providers
(JTeam, MetaCarta) and I'm partnering with other individuals to create a new
one. Expect to see more in the coming months. If you're looking for some
specific geospatial capabilities then let us know.
~ David Smiley
Author: http://www.packtpub.com/solr-1-4-enterprise
Ben,
It's absolutely possible for MLT to find documents similar to another
indexed document. That's its primary use case. For externally supplied
data, you will need to supply one blob of text. You could derive this by
concatenating applicable parts of your structured data before handing to
Hi Harish.
Did sorting on multiValued fields actually work correctly for you before?
I'd be surprised if so. I could be wrong but I think you previously always
got the sorting affects of whatever was the last indexed value. It is indeed
the case that the FieldCache only supports up to one
as complicated as it
gets.
References:
http://wiki.apache.org/solr/SolrQuerySyntax
http://wiki.apache.org/solr/CommonQueryParameters#sort
http://wiki.apache.org/solr/FunctionQuery#query
~ David Smiley
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
-
Author: https
.
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Custom-request-handler-plugin-tp2673822p2674267.html
Sent from the Solr - User mailing list archive at Nabble.com.
needn't know the set of
all super-admins at any time, just wether the current request is one.
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Custom-request-handler-plugin
configuration
you wanted. Well if that is the case, why didn't you add/enhance such
capabilities for an existing crawler?
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/ANNOUNCE
Wow; I'm glad you figured it out -- sort of.
FYI, in the future, don't hijack email threads to talk about a new subject.
Start a new thread.
~ David
p.s. yes, I'm working on the 2nd edition.
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in
I just noticed that field compression (e.g. compressed=true) is no longer
in Solr, nor can I find why this was done. Can a committer offer an
explanation? If the reason is that it eats up CPU, then I'd rather accept
this tradeoff for a big-data yet small query volume use case.
~ David Smiley
I'd consider using the logging framework. I do this with Log4j in other
apps. Its a generic approach that works for just about any system.
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3
a smaller distribution for them (~127MB vs 300-something) and put the data
files on MusicBrainz' servers which are downloaded as part of the setup
script you should run.
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context
clearly worthwhile.
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Endeca-vs-Solr-tp832826p832972.html
Sent from the Solr - User mailing list archive at Nabble.com.
.
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Endeca-vs-Solr-tp832826p833019.html
Sent from the Solr - User mailing list archive at Nabble.com.
to refer to a known value offset).
Following the link you gave is interesting though the general case I'm
talking about doesn't have a hierarchy. And I find the use of a single
multi-valued field unpalatable for a variety of reasons.
~ David Smiley
-
Author: https://www.packtpub.com/solr-1-4
if there are dates involved next
to impossible. This solution is really a hack workaround to a limitation
in Lucene/Solr. I was hoping to start a conversation to a more truer
resolution to this problem rather than these workarounds which aren't always
satisfactory.
~ David Smiley
-
Author: https
based on common multi-value field offsets
derived from matching term positions? I have no idea how far off the current
codebase is to exposing enough information to make such an approach possible.
~ David Smiley
From: Steven A Rowe [via Lucene]
[mailto:ml-node+684371-1863547009-13...@n3
that is. Thoughts?
~ David Smiley
--
View this message in context:
http://n3.nabble.com/One-item-multiple-fields-and-range-queries-tp475030p682227.html
Sent from the Solr - User mailing list archive at Nabble.com.
, Andrzej Bialecki wrote:
On 2010-03-23 06:25, David Smiley @MITRE.org wrote:
I use Endeca and Solr.
A few notable things in Endeca but not in Solr:
1. Real-time search.
2. related record navigation (RRN) is what they call it. This is the
ability to join in other records, something
, but I'll take Solr over it
any day -- at least I understand basically all of what's going on in Solr.
Of course I wrote the book on it so I'm biased ;-)
~ David Smiley
Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
Srikanth B wrote:
Hello
We are in the process
By the way, you'll probably want to shingle or use CommonGrams (with _BEGIN
_END being common) for acceptable performance.
I'm wondering, if Lucene's new payload features might provide an alternative
mechanism to mark the first and last term.
~ David Smiley
hossman wrote:
: Now, I know
the repo manager is now managed by Nexus at this URL:
https://repository.apache.org/index.html#nexus-search;quick~lucene
I could report a bug in Jira...
~ David Smiley
Author: http://www.packtpub.com/solr-1-4-enterprise-search-server/
hossman wrote:
: It seems the the latest lucene
agree that the mergeFactor is the upper bound of the
number of segments, then what is the lower bound of the number of segments
seen for an index that has not been optimized? Always 2, or some function
of mergeFactor?
~ David Smiley
Jay Hill wrote:
With a mergeFactor set to anything 1 you
I've always thought that these two events were effectively equivalent. --
the results of an optimize vs the results of Lucene _naturally_ merging all
segments together into one. If they don't have the safe effect then what is
the difference?
~ David Smiley
Otis Gospodnetic wrote:
Hello
201 - 300 of 322 matches
Mail list logo
