Hi Lukáš, hi Mark
> https://issues.apache.org/jira/browse/SOLR-839
thanks for pointing me there
> > although some parameters are available as URL parameters as well in ES
> Not sure if I understood exactly what you meant here but do you know you
> can always use "source" URL parameter to p
Hi Peter,
On Fri, Nov 18, 2011 at 12:11 AM, Peter Karich wrote:
>
>
> > I don't think it's possible.
>
> Eh, of course its possible (if I would understand it I would do it. no,
> no, just joking ;))
>
> and yes, Solr its a shorter for some common use cases. I don't think
> that there is a 'best'
The XML query parser can map to Lucene one to one as well - hasn't seemed
to pick up enough steam to be included with Solr yet, but there has been
some commotion so it's likely to go in at some point. Not enough demand yet
I guess. https://issues.apache.org/jira/browse/SOLR-839 XML Query Parser
Sup
All,
I'm using the excellent Grails web framework, and the documentation
tool it provides. The documenation tool allows you to write in wiki
and it will output fully formatted and linked documentation. What it
doesn't do is provide a search mechanism for docs (static html).
I think the best solut
> I don't think it's possible.
Eh, of course its possible (if I would understand it I would do it. no,
no, just joking ;))
and yes, Solr its a shorter for some common use cases. I don't think
that there is a 'best', but JSON can map 1:1 to lucene.
The biggest problem with ES's syntax is that
: > Maybe someone can post the equivalent query in ElasticSearch?
:
: I don't think it's possible. Hoss threw in the kitchen sink into his
: "contrived' example.
exactly ... i have no idea if that type of query is possible with ES, but
it was not intended to be an example of a "typical" Solr q
tl;dr version:
We're converting tons (hundreds of thousands?) of books into digital text.
What is the best format/markup/ebook standard/document standard/other to use
for easiest and best text search support?
***
Longer version;
The following are some desired user experience features of the p
Hi Erick,
Last time, processing the case again on a different box didn't give the
missing file error. But now, after two months, we see this again. We are
using lucene 2.x and java 1.x I believe.
I am wondering as to why does lucene need this .frq file as we have never
seen this issue in house, b
>
> Other parameters such as filters, faceting, highlighting, sorting,
> etc, don't normally have any hierarchy.
I regularly mix filters and queries inside Boolean logic. Attempts to structure
data (e.g. geocoding) don't always achieve 100% coverage and so for better
recall you must also resor
On Thu, Nov 17, 2011 at 3:44 PM, Michael McCandless
wrote:
> Maybe someone can post the equivalent query in ElasticSearch?
I don't think it's possible. Hoss threw in the kitchen sink into his
"contrived' example.
Here's a super simple example:
JSON:
{
"sort" : [
{ "age" : {"order"
On Thu, Nov 17, 2011 at 3:40 PM, Mark Harwood wrote:
> JSON or XML can reflect more closely the hierarchy in the underlying Lucene
> query objects.
We normally use the Lucene QueryParser syntax itself for that (not
HTTP parameters).
Other parameters such as filters, faceting, highlighting, sort
tl;dr version:
We're converting tons (hundreds of thousands?) of books into digital text.
What is the best format/markup/ebook standard/document standard/other to use
for easiest and best text search support?
***
Longer version;
The following are some desired user experience features of the p
Maybe someone can post the equivalent query in ElasticSearch? Then at
least we have a fair comparison of the two syntaxes, for this one
(complex) query at least...
Mike McCandless
http://blog.mikemccandless.com
On Thu, Nov 17, 2011 at 3:21 PM, Yonik Seeley
wrote:
> On Thu, Nov 17, 2011 at 3:18
I don't think of queries as inherently flat in the way HTTP request parameters
are with their name=value pairings.
JSON or XML can reflect more closely the hierarchy in the underlying Lucene
query objects.
For me using a "flat" query interface feels a bit like when you start off
trying to manag
On Thu, Nov 17, 2011 at 3:18 PM, Uwe Schindler wrote:
> Sorry, this query is really ununderstandable. Those complex queries should
> have a meaningful language, e.g. a JSON object structure
There are upsides and downsides to that. A big JSON object graph
would be easier to *read* but certainly n
> Or if you're just unjustifiably bitching about Solr again
Sorry, this query is really ununderstandable. Those complex queries should
have a meaningful language, e.g. a JSON object structure (like
XMLQueryParser, but instead JSON). Those queries are never entered by users
only by machines, why no
On Thu, Nov 17, 2011 at 8:03 PM, Yonik Seeley
wrote:
> On Thu, Nov 17, 2011 at 2:53 PM, Simon Willnauer
> wrote:
>> dude, look at this query... its insane isn't it :)
>
> Sorry... what's the equivalent you'd like instead?
oh, I think there are many ways to design a DSL for querying..
something I
On Nov 17, 2011, at 9:03 PM, Yonik Seeley wrote:
>> dude, look at this query... its insane isn't it :)
>
> Sorry... what's the equivalent you'd like instead?
> Or if you're just unjustifiably bitching about Solr again, maybe I
> should take a stroll through Lucene land and bitch about
> incompre
On Thu, Nov 17, 2011 at 2:53 PM, Simon Willnauer
wrote:
> dude, look at this query... its insane isn't it :)
Sorry... what's the equivalent you'd like instead?
Or if you're just unjustifiably bitching about Solr again, maybe I
should take a stroll through Lucene land and bitch about
incomprehensi
On Thu, Nov 17, 2011 at 9:25 AM, Peter Karich wrote:
>
>>> : "Think of the Query DSL as an AST of queries"
>>> : http://www.elasticsearch.org/guide/reference/query-dsl/
>>>
>>> I'm not familiar with ES, but FWIW: based on that one page the "Query DSL"
>>> doesn't really sound much more powerful th
Hi,
We faced a similar problem.
The solution was to give the indexer less work and let worker threads do
all the work. They would result in pre-processed/analyzed/tokenized
Documents that could be indexed by the writer without any processing.
Wouter
> Hi
>
> the file to be indexed depends on the
Hi
the file to be indexed depends on the type of Document / data extractor
My Document types are usually XML type and every time 2+ Million XML's
are indexed and time taken is less then 5 minuts.
with regards
karthik
On Fri, Nov 11, 2011 at 1:17 AM, Ian Lea wrote:
> And how long do
>> : "Think of the Query DSL as an AST of queries"
>> : http://www.elasticsearch.org/guide/reference/query-dsl/
>>
>> I'm not familiar with ES, but FWIW: based on that one page the "Query DSL"
>> doesn't really sound much more powerful then what you can do with nested
>> queries, local params, and
On Wed, Nov 16, 2011 at 10:18 PM, Chris Hostetter
wrote:
>
> : "Think of the Query DSL as an AST of queries"
> : http://www.elasticsearch.org/guide/reference/query-dsl/
>
> I'm not familiar with ES, but FWIW: based on that one page the "Query DSL"
> doesn't really sound much more powerful then wha
24 matches
Mail list logo
