I am a newbie to elasticsearch. i need a clarification. i can understand how routing works, but I have a question.
Can i create routing for an document with multiple field. if yes, can i search the
data using single routing value. Can any on provide any example about it.
Imagine I have 5 fields: [username,id,age,dept,salary]. Now i need to create a routing value for this document. Can I do so using the username and id field?
Thanks in advance.
In answer to your question: no, you can't automatically use multiple fields for a routing value when indexing a document. You can choose one and only one field, and that field must contain a single value.
However, you could manually concatenate the username and id field and pass it in the indexing request:
PUT /index/type/id?routing=username_id
{ body }
That said, routing is a feature for more advanced users. It is very useful but does make life more complicated. You say that you're a newbie, so I'd suggest not playing with routing just yet. That can follow when you're running a 50 node cluster.
Related
I want to work with Elasticsearch to process some Whatsapp chats. So I am initially planning the data load.
The problem is that the data exported from Whatsapp, doesn't contain a real unique id per user but it only contains the name of the user taken from the contact directory of the device where the chat is exported (ie. a user can change the number or have two numbers in the same group).
Because of that, I need to create a custom explicit mapping table between the user names and a self-generated unique id, that gets populated in an additional column.
Then, my question is: "How can I implement such kind of explicit mapping in Elasticsearch to generate an additional unique column?". Alternatively, a valid answer could be a totally different approach to the problem.
PS. As I write, I think the solution could be in the ingestion process, like in a python script, but I still want to post the question to understand if this is something that Elasticsearch can do by itself.
yes, do it during the index process
if you had the data that maps the name and the id stored in a separate index you could do this with an enrich processor when you index the data to add whichever value you want to the document via a pipeline
also - Elasticsearch doesn't have columns, only fields
I have an application that will have a front end that contains fields for a provider. One of the options is to be able to search for different providers. There can be up to 6 fields populated to search on or they can only submit one field for the search. For example, it can search on firstName, lastName, taxId or it can just search on lastName.
Can anyone steer me in the right direction on how to do this? I haven't been able to find any relevant tutorials for this specific problem. Any examples or links to this type of solution would be greatly appreciated. Thanks in advance.
isn't it become very complex for programmer to validate every possible combination what if there are 30 fields available then there will hundred's of combinations to validate. Is there any other solution for that.
Suppose I have a client with name, email, company attributes and I only need to search the name and email attributes.
Do I still need to send company attribute to elasticsearch and set index to false? or just send the required attributes only?
typically you would just index the entire document here. unless you have a massive data set (ie TBs), then the amount of savings you have would be minimal
and, from experience, there's a likely chance that someone will come along and ask to now search the company field, which means you will need to reindex everything to allow that
that said, yes you can definitely take that approach
I am writing a multi-language dictionary app. When the user selects a language to use data from, that language should apply to every page until they select a different language. Ideally, the language should be part of the URL so that the address for the English word "double" and the French word "double" is different. It should also be possible to specify no language, so that "double" would display both the English and the French word. I will also want to filter the data on multiple fields at the same time, e.g. the word itself and the language.
I'm trying to fit this into the Laravel resource concept. The index view of Word should show all words filtered by the language, or not filtered if no language is specified. create should keep the language from index. store should just use the form data. The language can be included as a hidden field in the create view if it's been specified. show doesn't strict speaking need a language filter, but if the user then goes back to index, the filter will still need to be applied.
I started using routes, but that means I'll have to hard-code a route for every filter. I've also thought of using session data, but that means the URLs wouldn't include the filter. If the filters are appended as a query string how would Laravel access them? Is this a good solution?
I'm using Laravel 5.8. What's the best Laravel way to persist this type of data filter across views?
I have similar issues in many areas of our apps. We occasionally use Session for this, but generally find the most efficient and easiest way to solve this is to attach a database field to the user object.
If you are using any type of auth, Laravel is already going to boot the user object on every page view, thus the filter can be pulled with no extra calls to the database. If no language is specified, the \Auth::user()->current_lang_id will be null, and thus no filter would be applied. We typically use a relationship (e.g. 'currentLang()') which makes it easy for the user to see the language and can automate binding on the form.
The nice part of this, we've found, is that it individualizes it per user, and it 'remembers' the user's preferences between sessions in a simple way - no need to make dozens of routes or a special variable + logic on multiple routes because those routes include your filter. Instead, you can put your logic at the top of a base controller and be done with it.
Lastly - changing the language when it is a db field on the user is just standard, simple CRUD.
HTH
CouchDB's versioning is an absolute boon to the application I'm writing, but each of the objects I want to represent in the database has it's own unique identifier (let's call it my_id), so I don't really need the _id field.
Is there a way for me to tell CouchDB that I want to make my field the primary hey (not _id)?
I'm using ruby's couchrest_model, so I know I can do Model.find_by_my_id(params[:my_id]) if I've put view_by :my_id in my class, but this feels like I'm storing an _id for no purpose. Should I care?
would it not be possible to, when you create the document, provide your own id instead of the default one couchb assigns? I don't know if ruby's couchrest can do it, but it's available in the CouchDB API
See here: http://wiki.apache.org/couchdb/HTTP_Document_API#PUT
The document ID is passed into the url.