What about rather than conflating field types for creating multiple
fields, use update processors to do the this expansion instead?
Erik
On Nov 26, 2009, at 10:04 AM, Grant Ingersoll wrote:
On Nov 25, 2009, at 8:24 PM, Chris Hostetter wrote:
I'm having a hard time wrapping my
On Nov 28, 2009, at 3:45 AM, Erik Hatcher wrote:
What about rather than conflating field types for creating multiple fields,
use update processors to do the this expansion instead?
How do you maintain the semantic information needed at search time? Are you
still having the field type (or
Hi,
Aren't search semantics the responsibility of a Query Parser and Querys
themselves? Just as the semantics of boolean queries are handled by the
standard Query parsers and BooleanQuery.
On Sat, Nov 28, 2009 at 3:17 PM, Grant Ingersoll gsing...@apache.orgwrote:
On Nov 28, 2009, at 3:45 AM,
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/987/
On Sat, Nov 28, 2009 at 9:41 AM, Chris Male gento...@gmail.com wrote:
Aren't search semantics the responsibility of a Query Parser and Querys
themselves? Just as the semantics of boolean queries are handled by the
standard Query parsers and BooleanQuery.
At a certain point, one needs
Hi,
There is some standardization of the syntax and semantics of range queries,
function queries and sorting that exists outside of the field types
themselves though. For example for range queries FieldType expects there is
just 2 values that define the range I think. Thats a requirement that
On Sat, Nov 28, 2009 at 10:51 AM, Chris Male gento...@gmail.com wrote:
By allowing each FieldType to have its own search semantics
We're far enough removed from an actual feature, I'm not sure if we're
disagreeing about anything concrete :-)
Going back to Grant's original question, I think it's
: SOLR-1600 ensures that for all mutivalued fields ,the response type is
: a collection.So your change is right
But that overlooks the potential problem i'm trying to point out: if your
change broke this test, then it could break a users code as well.
isn't there some protocol versioning
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-1131:
---
Attachment: SOLR-1131.patch
Here's a completely untested prototype patch along the lines of how I was
: I don't think it's useful to somehow programmatically access the list
: of fields that a fieldType could output.
based on my understanding of the potential types of use cases we're
talking about, i think i agree with you. It seems like the most crucial
aspect is that a FieldType has a way
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-1131:
---
Attachment: SOLR-1131.patch
Second try - forgot to svn add the new files.
Allow a single field type
Hey Hoss,
On 11/28/09 4:37 PM, Chris Hostetter hossman_luc...@fucit.org wrote:
One thing that concerns me is potential field name collision -- where one
of these new multifield producing FieldTypes might want to creat a name
that happens to collide with a field the user has already declared.
On Sat, Nov 28, 2009 at 7:37 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
Using Double underscores kind of feels like a hack, what i keep wondering
is if we can't leverage dynamicFields here.
This is what the prototype patch does I just put up on SOLR-1131.
I've gone with option A for
Integrate Near Realtime
Key: SOLR-1606
URL: https://issues.apache.org/jira/browse/SOLR-1606
Project: Solr
Issue Type: Improvement
Components: update
Affects Versions: 1.4
Reporter: Jason
use a proper key other than IndexReader for ExternalFileField and
QueryElevationCompenent to work properly when reopenReaders is set to true
[
https://issues.apache.org/jira/browse/SOLR-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Rutherglen updated SOLR-1606:
---
Attachment: SOLR-1606.patch
Solr config can have an index nrt (true|false), or commit can
16 matches
Mail list logo
