Hi,
>What our customers also want, is to be able to query on what a
>document for the end-user (customer) is : Some customers have the
>author of a document being some 'author node' referenced by the
>'document node' : Now, by the author's name, you do not find the
>document, because the authors n
On Mar 26, 2012, at 09:40 , Ard Schrijvers wrote:
> On Sat, Mar 24, 2012 at 3:12 PM, Lukas Kahwe Smith
> wrote:
>> Hi,
>>
>> I am not a Jackrabbit developer but a very interested user and co-lead of
>> the PHPCR [1] initiative.
>> I wanted to expand partially on what Ard said about potentiall
On Sat, Mar 24, 2012 at 3:12 PM, Lukas Kahwe Smith wrote:
> Hi,
>
> I am not a Jackrabbit developer but a very interested user and co-lead of the
> PHPCR [1] initiative.
> I wanted to expand partially on what Ard said about potentially looking into
> hooking in Solr/ElasticSearch [2] but some ot
On Mon, Mar 26, 2012 at 2:12 PM, Jukka Zitting wrote:
> ...As soon as we have a first draft
> to the indexing extension points (as described in the other thread)
> I'd love to see some prototypes on how they'd work in terms of
> external search indexes. Volunteers for that?...
I'd like to create
On Mar 26, 2012, at 09:31 , Ard Schrijvers wrote:
> On Mon, Mar 26, 2012 at 2:12 PM, Jukka Zitting
> wrote:
>>
>>> 3) "cleaner" data in results
>>
>> This goes into the discussion of what the query result abstraction in
>> the Oak API should look like. Breaking the requirement that all query
Hi,
On Sat, Mar 24, 2012 at 3:12 PM, Lukas Kahwe Smith wrote:
> More over (optionally) leveraging these has several other advantages:
Agreed, I think it would be great to have first-class integration from
Oak to *both* Solr and ElasticSearch. As soon as we have a first draft
to the indexing exte
