lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grant Ingersoll (JIRA)" <>
Subject [jira] Commented: (SOLR-1520) QueryElevationComponent does not work when unique key is of type 'sint'
Date Fri, 02 Jul 2010 21:30:52 GMT


Grant Ingersoll commented on SOLR-1520:

IRC log:
gsingers: I need to test solr w/ multiple unique keys
[16:48] gsingers: of different field types
[16:48] gsingers:
[16:48] gsingers: any suggestions?
[16:49] gsingers: seems like the Solr test case is pretty much one schema per
[16:49] gsingers: test class
[17:18] ThetaPh1: gsingers: is getStringIndex otherwise used in this, as Hoss mentioned?
[17:18] ThetaPh1: because lese it should work also with numeric fields and also sint, tint,...
[17:21] gsingers: ThetaPh1: I don't think getStringIndex is used anymore
[17:22] hossman: grant: there's a new JUnit4-esque base class that makes it easier to use
differnet configs in each test method ... you just call initCore(...) as needed in each test
[17:22] ThetaPh1: or in trunk the replacement...
[17:22] yonik__: getStringIndex is gone in trunk
[17:22] gsingers: it does still do FieldCache stuff
[17:22] ThetaPh1: yonik__: but the bytesref one?
[17:22] gsingers: but it is just BytesRef
[17:22] ThetaPh1: that is what i meant
[17:22] yonik__: gsingers: for schemas, just use schema11.xml - it has a float (actually sfloat)
unique key
[17:23] gsingers: yonik: OK, I can do that.  This should work for any field that is not tokenized,
[17:23] gsingers: as long as it is indexed
[17:23] yonik__: other code paths test the transformation from indexed to readable and back...
it's enough to test a single key that has a readable that is not identical to indexed
[17:24] yonik__: strictly speaking, tokenized should be fine too
[17:24] yonik__: or *can* be fine I should say
[17:24] gsingers: but what if you get multiple docs back?
[17:24] markrmiller left the chat room. (Quit: Commit this!)
[17:24] gsingers: I was debating that
[17:24] hossman: (FWIW: test like this are also possible with AbstractSolrTestCase -- you
just change the value getSchemaFile() returns before calling super.setUp(), but it's more
explicit in the new base class)
[17:25] gsingers: maybe it simply means elevate all those files
[17:25] yonik__: it's just like sorting
[17:25] gsingers: but, it is the unique key
[17:25] yonik__: if you're using the field cache, you won't get more than one doc per value
[17:25] gsingers: so, there shouldn't be more than one doc anyway
[17:25] yonik__: right
[17:25] yonik__: it actually could be tokenized, but should only result in one token
[17:26] gsingers: true, but that's a bit harder to enforce
[17:26] ThetaPh1: even when using getstringindex, trunk and 3.x should no longer throw exceptrion
[17:26] ThetaPh1: 3.0 does, but this was incorrectly fixed 
[17:26] gsingers: and seems like it could cause weird errors for people
[17:26] yonik__: gsingers: we don't enforce it for the unique key
[17:26] gsingers: OK
[17:26] yonik__: I don't believe
[17:26] ThetaPh1: and if you use tint as unique key, it should also work with stringindex
ahm termsindex
[17:26] yonik__: anyway, if it's enforced anywhere, that would be the place
[17:26] gsingers: I'm working on a diff. issue, anyone object to me c&p this onto the
[17:26] gsingers: so that I don't forget it
[17:27] yonik__: ?

> QueryElevationComponent does not work when unique key is of type 'sint'
> -----------------------------------------------------------------------
>                 Key: SOLR-1520
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>          Components: search
>    Affects Versions: 1.3
>         Environment: Gentoo Linux, Apache Tomcat 6.0.20, Java 1.6.0_15-b03
>            Reporter: Simon Lachinger
>            Assignee: Grant Ingersoll
>         Attachments: SOLR-1520.patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
> QueryElevationComponent does not work when unique key of the documents is of type 'sint'.
I did not try any other combination, but when I looking at the source in
I doubt it will work with any other type than string.
> I propose to either make it work with other data types or at least to post a warning.

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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message