On a very quick test, it looks like every integer value except 1 is
converted to "false" (I haven't looked at the underlying code, but
this sure makes sense).
So my guess is that what's being sent to Solr isn't what you think,
that is the varstatement you get back is something other than 1. I
have no real clue how DIH would return a bit type, perhaps the actual
value transmitted to Solr is...er...different....
So I'd look at two things:
1> Can you coerce the select statement to insure that an int is returned
for "varstatement".
2> Look at the DIH debug console to see what you can see. This is a
little-advertised page, see ....solr/admin/dataimport.jsp
Sorry I can't be more help..
Erick
On Mon, Jan 31, 2011 at 5:49 PM, PeterKerk <vettepa...@hotmail.com> wrote:
>
> Haha, I KNOW that to be very true: "I have done everything correct, its
> this
> stupid computer that doesnt understand me" ;)
>
> Anyway:
>
> <fieldType name="boolean" class="solr.BoolField" sortMissingLast="true"
> omitNorms="true"/>
>
> <field name="varstatement" type="boolean" indexed="true" stored="true"/>
>
> The reason I'm astonished the correct value isnt returned, is because the
> correct KVK number IS returned.
> So in this query: select KVK,varstatement FROM companies c INNER JOIN
> aspnet_users au on au.companyid=c.id WHERE au.userid =
> '${artist_owner.userid}'
>
> I see that the correct KVM number is indexed, but the varstatement value
> remains false even though in the DB it is true..
>
> On top of that I have successfully used the boolean fieldtype for other
> fields as well...
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/one-column-indexed-the-other-isnt-tp2389819p2392732.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
