lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uri Boness (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields
Date Wed, 23 Dec 2009 22:33:29 GMT

    [ https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794250#action_12794250
] 

Uri Boness commented on SOLR-1298:
----------------------------------

{quote}I think they should be inline, as they are just values associated with a document.
I think putting it in some other list is sticking too literally to what Lucene calls a field,
which I don't think Solr has to do that. One could easily imagine a Solr component that brought
in a database or other storage repository for supplementary fields and it should all be seamless
to the client.{quote}

I definitely agree that one shouldn't see a field in Solr as a field in Lucene. That said,
I think do have a tendency to see a field in Solr as somehow bound to the Solr schema. 

One thing to notice is that eventually we end up with the same discussion regarding this feature
in the context of different issues, let it be highlighting or field collapsing. In some cases
it feel just "right" to return the data as a field in a document, in other places it feels
"right" to have as something else. It is true that when you interact with solr directly (specially
if you do it manually) you certainly know what queries you send, what functions you request
and what you should expect in the result. But from experience, a lot of times you try to automate
things a bit and creating a well structured and descriptive protocols is the safe way to enable
that. 

{quote}I don't want to have to go look it up in some other list while I am iterating over
my results when all the other values I'm displaying/using are right there associated with
the document.{quote}

Having a sub-section under each documents still associates it with the document. The way I
see it, It's like OOP... you can have a Person class that holds all the information of the
person it it as primitive fields, or you can group related data, like address info, int a
separate Address class. 

{quote}That being said, it could be useful to add an attribute that indicates it is a generated
name{quote}

That's one way to group fields together, but if you're already doing that, then why not go
all the way? If you need to distinguish between generated and non-generated names, why not
make it simpler and just separate the two in a different list? (To continue the analogies
line I started above :-)) it's like XML, you can have a single level hierarchy were each element
defines attributes to relate it to other elements, but a more suitable solution would just
be to group all related elements under one parent element.

{quote}I'd even argue that highlighter results should be inline, too, but that is a different
issue and a bigger can of worms since it has a well used API already.{quote}
In some cases it might be (well it just is) more appropriate to have the highlighting inlined.
In other cases it might not be possible, specially with some of the latest requests to have
highlighting functionality available for arbitrary text loaded from anywhere (which I believe
will lead for a highlighting component/requestHandler that will be independent of the query
component).

{quote}Not saying this is right or wrong, but I think it would be useful to document here
the rationale about why not to do it. Is it just b/c that method is expected to do, more or
less, what the Lucene IndexSearcher does?{quote}
I guess so... I guess SolrIndexSearcher is in fact a Lucene IndexSearcher which is the source
for this association. In some ways I think it's also relates a bit to the response structure
(not directly though, but conceptually)... if the IndexSearcher represents Lucene and the
document contains fields coming from other sources as well, perhaps this functionality of
gathering all these fields (/metadata ;-)) should be done in a higher level where SolrIndexSearcher
just serves as on "field source". The main reason why Chris's patch puts this functionality
in the doc() method of the SolrIndexSearcher is simply because it's the easiest and the simplest
solution right now... and I don't thing there's nothing wrong with that... simple is good!
Even with this solution as it is, the "field sources" are still abstracted away in the form
of a "FieldValues" or "DocumentMutator", so architecture-wise I don't see leaving it as is
will compromise anything.

> FunctionQuery results as pseudo-fields
> --------------------------------------
>
>                 Key: SOLR-1298
>                 URL: https://issues.apache.org/jira/browse/SOLR-1298
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Grant Ingersoll
>            Assignee: Grant Ingersoll
>            Priority: Minor
>             Fix For: 1.5
>
>         Attachments: SOLR-1298-FieldValues.patch, SOLR-1298.patch
>
>
> It would be helpful if the results of FunctionQueries could be added as fields to a document.

> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the document
> 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message