Erick,
1."_version_ will change on updates" , shouldnt that be OK ?My
understanding of update here means that the a new document will be inserted
with the same unique key <docUrl> in my case ,which will replace the
document effectively. This will not be an issue in my case because the
initial search results based on <doctorName>, would have basic doctor data
, and when that tile is clicked upon detail data would be displayed based
on the lookup of the _version_ id. So if the _version_ does not change
besides the "update" , I should be good , of course there is a possibility
of the document being "updated" between the search results being displayed
and detailed information being requested, but the possibility of that less
in my case , because usually people request details as soon as the initial
search results are displayed.
2. Yes,I have used UUIDUPdateProcessorFactory in the following ways , but
none of them solve the issue , especially in SolrCloud.
*Case 1:*
*schema.xml*
<field name="id" type="string" indexed="true" stored="true"
required="true" multiValued="false" />
This does not generate the unique id at all.
*Case 2:*
<field name="id" type="uuid" indexed="true" stored="true"
required="true" multiValued="false" />
In this case a unique id is generated , but that is unique for every
replica and we end up with different ids for the same document in different
replicas.
In both the cases above the solrconfig.xml had the following entry.
<updateRequestProcessorChain name="uuid">
<processor class="solr.UUIDUpdateProcessorFactory">
<str name="fieldName">id</str>
</processor>
<processor class="solr.RunUpdateProcessorFactory" />
</updateRequestProcessorChain>
On Thu, Nov 13, 2014 at 11:01 AM, Erick Erickson <erickerick...@gmail.com>
wrote:
> _version_ will change on updates I'm pretty sure, so I doubt
> it's suitable.
>
> I _think_ you can use a UUIDUPdateProcessorFactory here.
> I haven't checked this personally, but the idea here is
> that the UUID cannot be assigned on the shard. But if you're
> checking this out, if the UUID is assigned _before_ the doc
> is sent to the destination shard, it should be fine.
>
> Have you checked that out? I'm at a conference, so I can't
> check it out too thoroughly right now...
>
> Best,
> Erick
>
> On Thu, Nov 13, 2014 at 10:18 AM, S.L <simpleliving...@gmail.com> wrote:
> > Here is why I want to do this .
> >
> > 1. My unique key is a http URL, doctorURL.
> > 2. If I do a look up based on URL , I am bound to face issues with
> > character escaping and all.
> > 3. To avoid that I was using a UUID for look up , but in SolrCloud it
> > generates unique per replica , which is not acceptable.
> > 4. Now I see that the mandatory _version_ field has a unique value per
> > document and and not unique per replica , so I am exploring the use of
> > _version_ to do a look up only and not neccesarily use it as a unique
> key,
> > is it do able in that case ?
> >
> > On Thu, Nov 13, 2014 at 8:58 AM, Erick Erickson <erickerick...@gmail.com
> >
> > wrote:
> >
> >> Really, I have to ask why you would want to. This is really purely an
> >> internal
> >> thing. I don't know what practical value there would be to search on
> this?
> >>
> >> Interestingly, I can search _version_:[1000000 TO *], but specific
> searches
> >> seem to fail.
> >>
> >> I wonder if there's something wonky going on with searching on large
> longs
> >> here.
> >>
> >> Feels like an XY problem to me though.
> >>
> >> Best,
> >> Erick
> >>
> >> On Thu, Nov 13, 2014 at 12:45 AM, S.L <simpleliving...@gmail.com>
> wrote:
> >> > Hi All,
> >> >
> >> > We know that _version_field is a mandatory field in solrcloud
> schema.xml,
> >> > it is expected to be of type long , it also seems to have unique value
> >> in a
> >> > collection.
> >> >
> >> > However the query of the form
> >> >
> >>
> http://server1.mydomain.com:7344/solr/collection1/select/?q=*:*&fq=%28_version_:1484632548944380000%29&wt=json
> >> > does not seems to return any record , can we query on the
> _version_field
> >> in
> >> > the schema.xml ?
> >> >
> >> > Thank you.
> >>
>
