[
https://issues.apache.org/jira/browse/SOLR-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884814#action_12884814
]
Grant Ingersoll commented on SOLR-1520:
---------------------------------------
IRC log:
{quote}
gsingers: I need to test solr w/ multiple unique keys
[16:48] gsingers: of different field types
[16:48] gsingers: https://issues.apache.org/jira/browse/SOLR-1520
[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 method
[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, right?
[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 issue?
[17:26] gsingers: so that I don't forget it
[17:27] yonik__: ?
{quote}
> QueryElevationComponent does not work when unique key is of type 'sint'
> -----------------------------------------------------------------------
>
> Key: SOLR-1520
> URL: https://issues.apache.org/jira/browse/SOLR-1520
> 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 QueryElevationComponent.java 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
