: - binary fields don't work. The results come back as "@B[]",
versus the actual data.
: - short fields get "java.lang.Short" text prefixed on every value.
these sound like they must be bugs in the javabin codec, certianly not
intentional
Ken: did you file jiras about these?
-Hoss
Thanks for the reply, Ken – it was your training session that brought the
dispatcher core approach to my attention in the first place.
Regarding your deep query point, if you're in a situation where numFound=5000
and you're trying to output all 5000 records at once – your point seems to
sugge
Hi Hector,
On Jan 9, 2012, at 4:15pm, Hector Castro wrote:
> Hi,
>
> Has anyone had success with multicore single node Solr configurations that
> have one core acting solely as a dispatcher for the other cores? For
> example, say you had 4 populated Solr cores – configure a 5th to be the
> d
My point is this - *everyone *using shards needs to handle that uniqueness.
Why not make it as a mechanism in Solr, with the ability to plugin our own
implementation of the hashing method?
Or is that what Solr Cloud is all about?
SJ
On Wed, Jan 11, 2012 at 4:33 PM, Hector Castro wrote:
> In ou
In our setup, we handle the document distribution and uniqueness across cores
outside of Solr.
--
Hector
On Jan 11, 2012, at 1:53 AM, shlomi java wrote:
> Straying a bit from the subject,
>
> don't you think it will be useful to have the shards parameter used also in
> the index, in order to m
Straying a bit from the subject,
don't you think it will be useful to have the shards parameter used also in
the index, in order to maintain document uniqueness?
I mean as an out of the box feature of Solr.
Because the situation today is that a Solr's client working with a sharded
Solr is respons
On 1/9/2012 5:15 PM, Hector Castro wrote:
Hi,
Has anyone had success with multicore single node Solr configurations that have
one core acting solely as a dispatcher for the other cores? For example, say
you had 4 populated Solr cores – configure a 5th to be the definitive endpoint
with `shar
In my case the cores are populated with different records that adhere to the
same schema. The question about randomly distributing requests is because each
core has the `shards` parameter populated so that it can hit the other core's
indexes.
My question is more about the advantages (if any) of
If you want to randomly distribute requests across shards, then I think
it's a case of Replication.
In Replication setup, all cores have the same schema AND data, so query any
core should return the same result. It is used to support heavy load. Of
course such setup will required some kind of load
Hi,
Has anyone had success with multicore single node Solr configurations that have
one core acting solely as a dispatcher for the other cores? For example, say
you had 4 populated Solr cores – configure a 5th to be the definitive endpoint
with `shards` containing cores 1-4.
Is there any ad
10 matches
Mail list logo
