I'm trying to construct XQuery that will return the count of the number attributes found that have a value of x.
This is part of SQL query and these counts will fill one of the columns returned (that part I can figure out, it's the actual XQuery to get the count I haven't figured out yet.)
For example, if I have <element elementattribute=1>...</element>, how would I count all the #elementattributes that equal 1 for a given chunk of XML?
you can use an asterisk wildcard for the element name:
count(//*[#elementattribute='1'])
Hope that helps...
Related
The Nebula Graph docs say that "When traversing all vertices of the specified Tag or edge of the specified Edge Type, such as MATCH (v:player) RETURN v LIMIT N, there is no need to create an index, but you need to use LIMIT to limit the number of output results." But when I run the statement in the preceding screenshot, it told me that I did not have a limit number, which I did.
What is the correct way to RETURN v without creating indexes?
I met the same issue before. Actually, when you specify both a tag and an edge for a query simultaneously, you need to create an index for the tag or the edge first.
Create an index for the tag company first and then try to execute it again.
We are storing a map in DynamoDB (not my design choice). So, basically a key can contain a list of values. Something like map[string][]someStruct.
We can only append a value to a given key if there are only N or less values for a given key. For example, if "key1" already has 3 values, I cannot append another value, but if it has less than 3 values, I can append one more value.
I looked at Conditional Writes, but couldn't find a conditional expression that would help with this. Any help is greatly appreciated. Thanks!
You would need to store the number of records in the list along side the list, perhaps something like this would work:
{
"key1": {
"list": [1,2,3,4],
"listLength": 4
}
}
You'll need to make sure that the list and listLength are kept in sync.
Alternatively you can get the item, check the length and then update with a condition to make sure it hasn't been updated between you get and update operation.
Why the following command is slow (5 mins)?
mytable | where extent_tags() contains "20210613" | count
I know this is not the best way to get count , I could have used .show table extents and could have simply calculated sum(RowCount) using summarize operator. But I am just testing. Ideally ADX should be able to search tags across extents and get counts , so it is only metadata search and once it finds correct extent, row count is already stored as part of the extent metadata anyways, so why should it take 5 mins? And by the, the extent(s) I am interested in has the following tag:-
drop-by:20210613
ingest-by:20210613
There is a datetime field in the table which I could have used to filter too , which is what adx ideally recommends in general scenarios and I can guess the reason that min and max of every datetime field in the table is stored in every extent of the table -- but then similarly even tag is stored in every extent. So which method is more efficient , filtering on a datetime field if available or tags?
a. you're correct that using .show table T extents where tags contains 'string' | ... would be much more efficient
b. as mentioned in the documentation: https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/extenttagsfunction
Filtering on the value of extent_tags() performs best when one of the following string operators is used: has, has_cs, !has, !has_cs.
c. which method is more efficient , filtering on a datetime field if available or tags?
The former, especially when your filter is on a substring, and not on the full content of the tag. Tags are a non-indexed metadata property of shards, and isn't an indexed data column. Also see: https://yonileibowitz.github.io/blog-posts/datetime-columns.html
I am writing a Dynamo Db .NET query with both "Limit" as well as "Filter Expression" as shown below:
var search = testTable.Query(new QueryOperationConfig
{
Filter = new QueryFilter("Name", QueryOperator.BeginsWith, "B"),
IndexName = "IsActive-gsi",
Limit = 5,
PaginationToken = paginationToken,
});
I expect that filter expression should be evaluated first and then limit condition is applied to the filtered result. But query seems to work in other way. That is, Limit condition is getting applied first and then filter expression is applied on the limited result. Due to this, I am not getting the expected result.
For example, say I have 10 rows in a table (with only one column of string type). Say first 5 rows starts with letter "A" and then 6th row starts with letter "B". I have added Limit as 5 and filter expression as "BeginsWith('B')" as shown above in the query. I expect to get at least one result(6th row) but query returns zero results.
My question: Is my query wrong or does Dynamo DB works this way? If it works this way, then how to get around this issue i.e. first apply filter expression on all rows and then apply limit condition, both in a single call to database?
FilterExpression do not actually change the query itself (i.e. all elements that match your query are returned from DynamoDB), but only limit the results afterwards. See the FilterExpression documentation:
A filter expression is applied after a Query finishes, but before the
results are returned.
So this means, that your observed behaviour is the expected behaviour.
I think to get the result you want, you need to make sure that the attribute on which you want to apply a filter is part of the key (i.e. probably the sort key), then you can use Key Condition Expressions.
So I have a graph that looks like this(starting from the rightmost side) with relationships that have a unique number attribute called Isnad. I want to write a query to get the length of every Isnad from the start node to the end node but I can't figure it out. I don't know how to traverse every path for every Isnad separately. Any help?
I don't know if it is the most elegant and solution, but I think it works. First, I'm getting all unique Isnad values of relationships outgoing from the rightmost side node using an identifier. Then I'm using a variable-length pattern matching where all relationships have the same value for Isnad property. Then the Isnad value and the path length are returned.
match ({id:'unique-identifier-of-rightmost-side-node'})-[r]->()
with distinct r.Isnad as Isnad
match p = ()-[*{Isnad : Isnad}]->()
return Isnad, length(p) as Length