TestContentStreamDataSource failing on trunk

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

TestContentStreamDataSource failing on trunk

hossman

the lucene zone machine is down (see INFRA-2351) so i don't think nightly
builds are running.

On my local box i'm seeing TestContentStreamDataSource fail...

junit.framework.AssertionFailedError: expected:<Hello C1> but was:<[Hello C1]>
  at org.apache.solr.handler.dataimport.TestContentStreamDataSource.testSimple(TestContentStreamDataSource.java:67)


Noble: is it possible this was caused by your SOLR-1600 changes? (which
don't seem to be listed in CHANGES.txt ... what's up with that?!?)

i think that "[]" syntax is ant's way of stringifying a collection.  If i
modify the test like this...

-    assertEquals("Hello C1", doc.getFieldValue("desc"));
+    assertEquals("Hello C1", doc.getFirstValue("desc"));

...it starts to pass, but i don't just wnat to commit that change without
being sure we understand why it broke in the firstplace, and wether it's
an indication of how something might break for end users.

-Hoss

Reply | Threaded
Open this post in threaded view
|

Re: TestContentStreamDataSource failing on trunk

Noble Paul നോബിള്‍  नोब्ळ्-2
SOLR-1600 ensures that for all mutivalued fields ,the response type is
a collection.So your change is right
On Thu, Nov 26, 2009 at 8:38 AM, Chris Hostetter
<[hidden email]> wrote:

>
> the lucene zone machine is down (see INFRA-2351) so i don't think nightly
> builds are running.
>
> On my local box i'm seeing TestContentStreamDataSource fail...
>
> junit.framework.AssertionFailedError: expected:<Hello C1> but was:<[Hello
> C1]>
>        at
> org.apache.solr.handler.dataimport.TestContentStreamDataSource.testSimple(TestContentStreamDataSource.java:67)
>
>
> Noble: is it possible this was caused by your SOLR-1600 changes? (which
> don't seem to be listed in CHANGES.txt ... what's up with that?!?)
>
> i think that "[]" syntax is ant's way of stringifying a collection.  If i
> modify the test like this...
>
> -    assertEquals("Hello C1", doc.getFieldValue("desc"));
> +    assertEquals("Hello C1", doc.getFirstValue("desc"));
>
> ...it starts to pass, but i don't just wnat to commit that change without
> being sure we understand why it broke in the firstplace, and wether it's an
> indication of how something might break for end users.
>
> -Hoss
>
>



--
-----------------------------------------------------
Noble Paul | Principal Engineer| AOL | http://aol.com
Reply | Threaded
Open this post in threaded view
|

Re: TestContentStreamDataSource failing on trunk

hossman

: 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 information in the javabin format
that can be rev'ed here? ... that's what we did with the "version" param
for the XMLResponseWriter when a similar change was made to it a few years
back.

: > ...it starts to pass, but i don't just wnat to commit that change without
: > being sure we understand why it broke in the firstplace, and wether it's an
: > indication of how something might break for end users.



-Hoss