JSONPath with hamcrest hasSize() - citrus-framework

When using the hasSize matcher in the form of #assertThat(hasSize(x))# with a jsonpath expression that returns an array, duplicate values will not be taken into account. Example :
{
"a":[
{
"value1":"ab",
"value2": 2
},
{
"value1":"ab",
"value2":2
}
]
}
If I execute payload().validate("$..value1", "#assertThat(hasSize(2))#") it will result in an error as hasSize will expect a collection of size 1 instead of 2. Is this the desired behavior of the matcher? A workaround would be to use the expression "$.a[?(#.value1)]".

Summary
This is a bug in Citrus. As mentioned in my comment, I have tracked down the bug, see GitHub issue.
I have also fixed the bug and opened a GitHub Pull Request. However, it may take some weeks for my changes to be reviewed by the main Citrus maintainer, since he is currently working on a different project.
I am positive that the fix will be included in the next Citrus maintenance release 2.7.3.
Notes
This bug only occurs if some of the values are duplicate entries, due to a code fragment which uses a Set, which by definition cannot hold duplicate entries.
Example (copied from the GitHub Issue)
{
"test_array": [
{
"key_with_identical_values": "identical_value",
"key_with_unique_values": "unique_value"
},
{
"key_with_identical_values": "identical_value",
"key_with_unique_values": "different_unique_value"
}
]
}
Given the Citrus validation as follows:
<receive endpoint="testServer">
<message type="json">
<validate>
<json-path expression="$..key_with_unique_values" value="#assertThat(hasSize(2))#"/>
<json-path expression="$..key_with_identical_values" value="#assertThat(hasSize(2))#"/>
</validate>
</message>
</receive>
Even though the JSONPath array for both expressions is of size 2 (["unique_value", "different_unique_value"] and ["identical_value", "identical_value"]), the validation will fail for the expression $..key_with_identical_values with the message:
Expected: a collection with size <2>
but: collection size was <1>

Related

How do I perform aggregate queries using SumoLogic APIs

I am trying to perform aggregate queries using SumoLogic APIs as mentioned here.
Something like:
_view = <some_view> | where sourceCategory matches \"something\" | sum(field) by sourceCategory
This works just fine in the Sumo GUI. I get a field in result called "_sum" which gives me the desired result.
However the same doesn't work when I do it using the SUMO APIs. If I create a job with this body:
{
"query": "_view = <some_view> | where sourceCategory matches "something" | sum(field) by sourceCategory",
"from": "start_timestamp",
"to": "end_timestamp",
"timeZone": "some_timezone"
}
I call the "v1/search/jobs" POST method with the above body and I do GET "v1/search/jobs/{job_id}" till the state is "DONE GATHERING RESULTS". Then I do "v1/search/jobs/{job_id}/messages". I was expecting to see aggregated values in the result, but instead I see something similar to:
{
"fields":[
{
"name":"_messageid",
"fieldType":"long",
"keyField":false
}, ...
],
"messages":[
{
"map":{
"_receipttime":"1359407350899",
"_size":"549",
"_sourcecategory":"service",
"_sourceid":"1640",
"the_field_i_mentioned":"not-aggregated-value"
"_messagecount":"2044"
}
}, ...
]
]
Thanks for going through my question. Any advices / work-arounds are appreciated. I don't really want to iterate manually through all items and calculate the sum. I'd prefer to do it on SumoLogic side itself. Thanks Again!
Explanation
Similar as in the User Interface, in the API for log searches you get both raw results (also referred to as messages) and the aggregate results (also referred to as records).
(Obviously, the latter are only returned if there's any aggregation in the query. In your case there is.)
Actual suggestion
Then I do "v1/search/jobs/{job_id}/messages"
Try /records instead.
See the docs for "Paging through the records found by a Search Job"
Disclaimer: I am currently employed by Sumo Logic.

Protractor - check if element is present and either stop test or continue

I have a Protractor test that pulls various values from the UI and stores them as variables for comparison with values from a different database.
Now this test needs to run against multiple sites BUT of the 25 maximum data points recorded, some sites only have 22.
Clearly the test fails on those "22" sites since the elements are not present.
What I want to achieve is where there's a "22" site, the tests against the not present elements are ignored and the test proceeds to the end. Conveniently, the "missing" elements are the last ones in the spec.
Crudely speaking...
if element-y is not present end test or if element-y is present continue
Grateful if anyone could advise.
Thanks #sergey. I've modified your example as below....
if (!(await element(by.xpath('//*[#id="root"]/div/div[2]/main/div/div/section[5]/div/div/div[1]/section/div/span')).isPresent())) {
console.warn ('Functions are not present, closing the session')
await browser.close()
I get this error:
if (!(await element(by.xpath('//*[#id="root"]/div/div[2]/main/div/div/section[5]/div/div/div[1]/section/div/span')).isPresent())) {
^^^^^^^
SyntaxError: Unexpected identifier
I've tried using a 'var' instead of the actual element, but get the same result.
Thanks
well the best option that I recall is still pretty dirty... you can do something like this
if (!(await element.isPresent())) {
console.warn('Element not present, closing the session')
await browser.close()
}
And then the rest of test cases will fail as session not found or similar error
The reason you can't do anything better because in protractor you can't do conditional test cases based on a Promise-like condition, if that makes sense...

TOML multi-level table syntax inside array -- illegal or not

I'm seeing an error during parsing with the Python and JS parsers. I can't seem to find an example in the TOML repo about whether this should be accepted or not:
[[somearray]]
one.two = false # fails, '.' not allowed in key
I know I can express this as:
[[somearray]]
[somearray.one]
two = false # OK
The TOML readme offers this example (among others):
[fruit]
apple.color = "red"
apple.taste.sweet = true
which does not involve arrays but seems to legitimize this syntax.
I also observe that a plain file with this content:
apple.color = "red"
is rejected. In conclusion, until you enter "table mode" (so to say) with an actual bracketed table, keys can only be singles.
Now again, in the TOML readme it says (although in the tables section):
"Dotted keys define everything to the left of each dot as a table."
Obviously, if mainstream parsers choke on it, it's not a good idea to use it, but I'd like to understand if/why it's a known no-no. Is here some ambiguity I'm not seeing?
These cases are confirmed valid TOML, per the 1.0 spec, which adds many more examples: https://github.com/toml-lang/toml/blob/1.0.0/toml.md
The following is definitely valid Toml syntax:
[[somearray]]
one.two = false
It should result in a model that is equivalent to this Json syntax:
{
"somearray": [
{
"one": {
"two": false
}
}
]
}
It can be validated here.
Dotted keys should indeed define everything to the left of each dot as a table.

How does resource.data.size() work in firestore rules (what is being counted)?

TLDR: What is request.resource.data.size() counting in the firestore rules when writing, say, some booleans and a nested Object to a document? Not sure what the docs mean by "entries in the map" (https://firebase.google.com/docs/reference/rules/rules.firestore.Resource#data, https://firebase.google.com/docs/reference/rules/rules.Map) and my assumptions appear to be wrong when testing in the rules simulator (similar problem with request.resource.data.keys().size()).
Longer version: Running into a problem in Firestore rules where not being able to update data as expected (despite similar tests working in the rules simulator). Have narrowed down the problem to point where can see that it is a rule checking for request.resource.data.size() equaling a certain number.
An example of the data being passed to the firestore update function looks like
Object {
"parentObj": Object {
"nestedObj": Object {
"key1": Timestamp {
"nanoseconds": 998000000,
"seconds": 1536498767,
},
},
},
"otherKey": true,
}
where the timestamp is generated via firebase.firestore.Timestamp.now().
This appears to work fine in the rules simulator, but not for the actual data when doing
let obj = {}
obj.otherKey = true
// since want to set object key name dynamically as nestedObj value,
// see https://stackoverflow.com/a/47296152/8236733
obj.parentObj = {} // needed for adding nested dynamic keys
obj.parentObj[nestedObj] = {
key1: fb.firestore.Timestamp.now()
}
firebase.firestore.collection('mycollection')
.doc('mydoc')
.update(obj)
Among some other rules, I use the rule request.resource.data.size() == 2 and this appears to be the rules that causes a permission denied error (since commenting out this rules get things working again). Would think that since the object is being passed with 2 (top-level) keys, then request.resource.data.size()=2, but this is apparently not the case (nor is it the number of keys total in the passed object) (similar problem with request.resource.data.keys().size()). So there's a long example to a short question. Would be very helpful if someone could clarify for me what is going wrong here.
From my last communications with firebase support around a month ago - there were issues with request.resource.data.size() and timestamp based security rules for queries.
I was also told that request.resource.data.size() is the size of the document AFTER a successful write. So if you're writing 2 additional keys to a document with 4 keys, that value you should be checking against is 6, not 2.
Having said all that - I am still having problems with request.resource.data.size() and any alternatives such as request.resource.size() which seems to be used in this documentation
https://firebase.google.com/docs/firestore/solutions/role-based-access
I also have some places in my security rules where it seems to work. I personally don't know why that is though.
Been struggling with that for a few hours and I see now that the doc on Firebase is clear: "the request.resource variable contains the future state of the document". So with ALL the fields, not only the ones being sent.
https://firebase.google.com/docs/firestore/security/rules-conditions#data_validation.
But there is actually another way to ONLY count the number of fields being sent with request.writeFields.size(). The property writeFields is a table with all the incoming fields.
Beware: writeFields is deprecated and may stop working anytime, but I have not found any replacement.
EDIT: writeFields apparently does not work in the simulator anymore...

Apply Command to String-type custom fields with YouTrack Rest API

and thanks for looking!
I have an instance of YouTrack with several custom fields, some of which are String-type. I'm implementing a module to create a new issue via the YouTrack REST API's PUT request, and then updating its fields with user-submitted values by applying commands. This works great---most of the time.
I know that I can apply multiple commands to an issue at the same time by concatenating them into the query string, like so:
Type Bug Priority Critical add Fix versions 5.1 tag regression
will result in
Type: Bug
Priority: Critical
Fix versions: 5.1
in their respective fields (as well as adding the regression tag). But, if I try to do the same thing with multiple String-type custom fields, then:
Foo something Example Something else Bar P0001
results in
Foo: something Example Something else Bar P0001
Example:
Bar:
The command only applies to the first field, and the rest of the query string is treated like its String value. I can apply the command individually for each field, but is there an easier way to combine these requests?
Thanks again!
This is an expected result because all string after foo is considered a value of this field, and spaces are also valid symbols for string custom fields.
If you try to apply this command via command window in the UI, you will actually see the same result.
Such a good question.
I encountered the same issue and have spent an unhealthy amount of time in frustration.
Using the command window from the YouTrack UI I noticed it leaves trailing quotations and I was unable to find anything in the documentation which discussed finalizing or identifying the end of a string value. I was also unable to find any mention of setting string field values in the command reference, grammer documentation or examples.
For my solution I am using Python with the requests and urllib modules. - Though I expect you could turn the solution to any language.
The rest API will accept explicit strings in the POST
import requests
import urllib
from collections import OrderedDict
URL = 'http://youtrack.your.address:8000/rest/issue/{issue}/execute?'.format(issue='TEST-1234')
params = OrderedDict({
'State': 'New',
'Priority': 'Critical',
'String Field': '"Message to submit"',
'Other Details': '"Fold the toilet paper to a point when you are finished."'
})
str_cmd = ' '.join(' '.join([k, v]) for k, v in params.items())
command_url = URL + urllib.urlencode({'command':str_cmd})
result = requests.post(command_url)
# The command result:
# http://youtrack.your.address:8000/rest/issue/TEST-1234/execute?command=Priority+Critical+State+New+String+Field+%22Message+to+submit%22+Other+Details+%22Fold+the+toilet+paper+to+a+point+when+you+are+finished.%22
I'm sad to see this one go unanswered for so long. - Hope this helps!
edit:
After continuing my work, I have concluded that sending all the field
updates as a single POST is marginally better for the YouTrack
server, but requires more effort than it's worth to:
1) know all fields in the Issues which are string values
2) pre-process all the string values into string literals
3) If you were to send all your field updates as a single request and just one of them was missing, failed to set, or was an unexpected value, then the entire request will fail and you potentially lose all the other information.
I wish the YouTrack documentation had some mention or discussion of
these considerations.