Hi Gora,
Thanks a lot for your reply.
"As people have already advised you, the best way to decide
how to organise your data in the Solr index depends on the
searches that you want to make. This is not entirely clear
from your description above. The flattening sample that you
show above would be suitable if the user is to search by
'child' attributes, but can be simplified otherwise."
*Yes, the search is based on the child attributes.*
"How would you know that the user name has been changed?
Is there a modification date for that table. If so, it would make
sense to check that against the last time indexing to Solr was
done. A DIH delta-import makes this straightforward."
*As of now, there is no special column to know if the username has been
changed.
*
*But, whenever the user update his name, i can track that in my java code
and send the update to Solr.
*
*Here, I am planning to use Solr java client.
*
*But, all the above things are possible with Java client and also with
delta-import.
*
*I am looking for changing the solr data whenever there is a change in the
database.*
*Even there is a small delay i am fine with that.
*
*Which one you will suggest?
*
*Solr Java client or DIH delta-import????
*
*My application running on server A, database on server B and solr will be
on server C.
*
*If i am supposed to use, Solr Java client, i may need to hit the database
sometimes to get some parent data and then need to send the same to Solr.
*
*Guess, its a unnecessary trip.
*
*So confused here, if i need to go with Java client or DIH delta import.
*
Thanks,
Baskar.S
On Mon, Sep 16, 2013 at 9:23 AM, Gora Mohanty <g...@mimirtech.com> wrote:
> On 16 September 2013 02:47, Baskar Sikkayan <baskar....@gmail.com> wrote:
> [...]
> > Have a question now.
> >
> > I know in solr its flat file system and the data will be in denormalized
> > form.
> >
> > My question :
> >
> > Have 3 tables,
> >
> > 1) user (userid, firstname, lastname, ...)
> > 2) master (masterid, skills, ...)
> > 3) child (childid, masterid, userid, ...)
> >
> > In solr, i have added all these field for each document.
> >
> > Example,
> >
> > childid,masterid,userid,skills,firstname,lastname
> >
> > Real Data Example,
> >
> > 1(childid),1(masterid),1(userid),"java,jsp","baskar","sks"
> > 2(childid),1(masterid),1(userid),"java,jsp","baskar","sks"
> > 3(childid),1(masterid),1(userid),"java,jsp","baskar","sks"
>
> As people have already advised you, the best way to decide
> how to organise your data in the Solr index depends on the
> searches that you want to make. This is not entirely clear
> from your description above. The flattening sample that you
> show above would be suitable if the user is to search by
> 'child' attributes, but can be simplified otherwise.
>
> > The above data sample is from solr document.
> > In my search result, i will have to show all these fields.
> >
> > User may change the name at any time.The same has to be updated in solr.
> >
> > In this case, i need to find all the child id that belongs to the user
> and
> > update the username with those child ids.
> >
> > Please tell me if there is any other better approach than this.
>
> How would you know that the user name has been changed?
> Is there a modification date for that table. If so, it would make
> sense to check that against the last time indexing to Solr was
> done. A DIH delta-import makes this straightforward.
>
> Updates as you suggest above would be the normal way to handle
> things. You should batch your updates, say by running an update
> script at periodic intervals.
>
> Regards,
> Gora
>
