version: 1.15.2
r.db('test')
.table('form')
.filter(r.row('yyy').eq('aaa').or(r.row('id').eq('aaa')))
.limit(10)
Why this query cannot match a document where id is aaa but without field yyy
There is special handling for non-existing fields (default: false) so I guess it is best to rewrite the query to not call .eq() on a missing field. You could either check id first:
.filter(r.row('id').eq('aaa').or(r.row('yyy').eq('aaa')))
or maybe by setting the default behavior directly on the operation with missing fields:
.filter(r.row('yyy').eq('aaa').default(false).or(r.row('id').eq('aaa')))
BTW: an update to this answer. After reporting a documentation bug for RethinkDB it turns out, this is already mentioned in a troubleshooting guide: http://www.rethinkdb.com/docs/troubleshooting/#filters-with-or-return-incorrect/unexpected-r
Related
I am trying to run the below code in Python using Elasticsearch Ver 7.1, however the following errors come up:
ElasticsearchDeprecationWarning: [types removal] Using include_type_name in put mapping requests is deprecated. The parameter will be removed in the next major version.
client.indices.put_mapping(index=indexName,doc_type='diseases', body=diseaseMapping, include_type_name=True)
followed by:
ElasticsearchDeprecationWarning: [types removal] Specifying types in document index requests is deprecated, use the typeless endpoints instead (/{index}/_doc/{id}, /{index}/_doc, or /{index}/_create/{id}).
client.index(index=indexName,doc_type=docType, body={"name": disease,"title":currentPage.title,"fulltext":currentPage.content})
How I am supposed to amend my code to make it (see here) work in line with Elasticsearch 7X version? Any kind of help would be much appreciated.
This is just a warning right now, but it will become an error in Elasticsearch 8.
From last few version, Elasticsearch has been planning the removal of index types inside an index
ES5 - Setting index.mapping.single_type: true on an index will enable the single-type-per-index behavior which will be enforced in 6.0.
In ES6 - you can't have more than 1 index type inside 1 index
In ES7 - the concept of types inside an index has been deprecated
In ES8 - it will be removed, and you can't use types for query or while inserting documents
My suggestion would be to design an application and mapping in such a way that it doesn't include type parameter in index
To know the reason why elastic search has done this here is a link: https://www.elastic.co/guide/en/elasticsearch/reference/current/removal-of-types.html#_why_are_mapping_types_being_removed
A common issue (and difficult to spot) for this error message could be misspelling the endpoint, e.g.:
Misspelled:
/search
Correct:
/_search
Double check if your endpoint is correct as ElasticSearch may think you are trying to manipulate (add, update, remove) a document and you are giving a type, which is not the case (you are trying to call an endpoint).
I am using TCP client to perform delete operation.
sample code:
DeleteRequestBuilder builder = client.prepareDelete(indexName, indexType,indexDocumentId);
ListenableActionFuture<DeleteResponse> deleteResponse = builder.setOperationThreaded(false).execute();
deleteResponse.actionGet(ESTemplateHelper.INDEX_STATE_ACK_TIMEOUT);
deleteStatus = deleteResponse.isDone();
I am passing empty value/"" to indexDocumentId.
deleteStatus is always true for empty documentId. But document is not deleted. am i missing something? Isn't it expected to throw any error?
The prepareDelete command is for deleting a single document by its ID. For more information: https://www.elastic.co/guide/en/elasticsearch/client/java-api/1.7/delete.html
Now, the ID of a document cannot be empty string. So, there should be no such document. The reason deleteStatus is true because it holds the value "whether the request is done or not?" and not "was the document deleted?". If you drill down the response, I believe you will find: found = false.
In case, you are passing an empty string in the hope of deleting all the documents of type indexType in the index indexName, then prepareDelete is not the right API for that.
Maybe, you can execute a query on all documents in your type, and delete them one by one. There is also delete by query API but it has been deprecated in 1.5 and removed in 2.0 because it can potentially cause OOM errors. More details here: https://www.elastic.co/guide/en/elasticsearch/reference/1.6/docs-delete-by-query.html
In case, you don't care about this index altogether, then deleting the index is the quickest and cleanest way to go: https://www.elastic.co/guide/en/elasticsearch/reference/1.7/indices-delete-index.html. I believe in the similar fashion you can delete your type too.
Eg: curl -XDELETE http://localhost:9200/indexName/indexType
I have added a custom issue type called 'Customer problem' in my JIRA installation. When I do a JQL query on a list like this:
project = MYPROJECT ORDER BY issuetype ASC
The resulting list shows the 'bug' issue type on top, after that my Customer problems and then the rest.
How can I prioritize my own custom issue type over the standard bug issue type?
I think the following happens:
ORDER BY x ASC does order alphabetical. The issuetype "bug" is probably alphabetically in front of your custom issuetype.
A solution with this searchterm could be renamming your custom type to a name with "a_oldname". That brings the name to the front... Not exactly elegant but a workaround.
You could also exclude bugs from the search results:
project = MYPROJECT AND issuetype NOT " bug" ORDER BY issuetype ASC
Alternatively we could try creating a search term that will order things differently... But on a mobile device I currently can't test my thoughts on that...
It seems like this solved my own question:
Go to Administration -> Issues -> Issue Type Schemes and click edit. There you'll get a screen which enables you to do exactly what is intended here:
The proper JQL-query to get the required result is now the one in the question.
We have a sitecore support ticket open for this issue, but I hope I could get someone else that's experienced this issue also.
Here is the output from my immediate window while debugging my sitecore 6.6 instance:
?db.SelectSingleItem("/sitecore/content/Www/Data/Recruiting/Metadata/Companies/00000001/*[##name='0000001873']")
null
?db.SelectSingleItem("/sitecore/content/Www/Data/Recruiting/Metadata/Companies/00000001/*")
0000001873 (en#1#web), id: {1848E256-E7C2-4BFC-9AF7-72EE14E37C82}
Database: "web"
Id: "{1848E256-E7C2-4BFC-9AF7-72EE14E37C82}"
Language: "en"
Name: "0000001873"
Version: "1"
Basically when I run either SelectSingleItem or GetItem and include any attribute (##id or ##name), I get null returned. However, if I remove the filtering attribute I do get a result set. Notice that the result set I get without the filter, is the first item in the list, is also the item I'm searching for with the ##name attribute.
I get this result ONLY in code. Using xPath designer I get a result.
I encountered a similar issue and it ended up being a folder whose name started with the number zero. I chalked it up as a potential issue with the way Sitecore parses queries and didn't look into it much further. Try escaping the folder name like so:
/sitecore/content/Www/Data/Recruiting/Metadata/Companies/#00000001#/*[##name='0000001873']
I am facing a problem with the admin generator and I am unable to get my way around this after 3 hours of brainstorming and exploring.
The error reads as:
500 | Internal Server Error | Doctrine_Record_UnknownPropertyException
Unknown record property / related component "option1" on "Questions"
Looking up the WWW, I got a gist of possible alternatives. None of which seem like the answer. option1, does exist under Questions schema. However, it is option_1 so I am not sure why it says option1. More importantly, opening up BaseQuestions.class.php file, it clearly states:
getOption1() retrieves the value of option_1.
Anybody with any answer on this?
Thanks,
I had just the same problem with a field named address_2. Changing the name of the field in the database to address2 solved the problem. I think that that this is because of the number that confuse the admin generator to translate the name from underscore-separated propriety name to camelCase function name. This issue append only with the admin generator so, if you need to use it you have to change the field name in your DB with option1.