I'm trying to run the same query that I use on the Google Analytics web application with The google analytics reporting API.
I want an advanced filter to check pageviews for urls with a specific folder (/folder/) and must ignore pageviews that have a specific source (ignore).
I have this:
{
"reportRequests":
[
{
"viewId": "xxxx",
"dateRanges": [{"startDate": "2020-02-01", "endDate": "2020-02-21"}],
"metrics": [{"expression": "ga:pageviews"}],
"dimensionFilterClauses": [{"filters": [{"dimensionName": "ga:pagePath","operator": "BEGINS_WITH","expressions": ["/folder/"]}]},{"filters": [{"dimensionName": "ga:source","operator": "!=","expressions": ["ignore"]}]}]
}
]
}
The /folder/ part is ok. But I don't know how to exclude the ignore.
Could you help me?
I've set up filters before similar to how you're wanting to use them here.
I use essentially a combination of the following:
Dimension Filters:
== Exact match
!= Does not match
=# Contains substring
!# Does not contain substring
=~ Contains a match for the regular expression
!~ Does not match regular expression
Combining Filters with “And” and “Or” Operators:
And “ ; ”
Or “ , “
I have a repo with example code of report requests that you can repurpose if that assists you here: https://github.com/jessfeliciano/aggregateGoogleAnalyticsReporting/blob/master/objectQueryWithFilter.js
I hope this helps, let me know if you have any follow up questions.
Related
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.
We have a couple of issues in Jira Cloud having names that contain multiple special characters. Examples:
My i$$ue
#nother issue
R&D related issue
s#me issue
s###me issue
$simple issue
Looking for a way of searching issues using REST API.
First I tried simple GET search like this: akceptor.atlassian.net/rest/api/3/issue/picker?query=s#me
It returns issues with 's#me' clause in the name but if you use partial name in search i.e. ?query=s# - the issue with name containing ### won't be found. Also does not work for &, $ and some other characters.
The next thing I tried was POST search using JQL. I.e. hitting akceptor.atlassian.net/rest/api/3/search resource with the following body:
{
"expand": [
"names"
],
"jql": "text ~ \"s#\"",
"maxResults": 15,
"fieldsByKeys": false,
"fields": [
"summary",
"status",
"assignee"
],
"startAt": 0
}
This found 's###me issue' but not 's#me issue'.
Worked better for issue names containing & and $ characters but still requires a full word to be included in the JQL query in some cases.
Documentation available gives a list of unsupported special characters but it looks like there is an issue with words containing chains of supported characters as well.
Any ideas how to properly search for both 's#me' and 's###me'?
Especially in cases when we don't want to specify the beginning of word (i.e. we are interested in something ending with '#me')
Contacted Atlassian supports and they confirmed a bug:
If you perform a search using special character in the quick search, it will return no results.
Affected characters:
/ _ - &
https://jira.atlassian.com/browse/JRACLOUD-71066
I have an entity called #spare_part and this entity has 4 values with the following example synonyms each:
both with synonyms filter, oil level indicator
not_defined with a synonym spare part
only_gear with synonyms valve, seal
whole_gear_box with a synonym complete set of gearbox
I want to be able to handle multiple entities given in the same input and address them later on, if needed. With this purpose I have coded the following in JSON editor:
{
"context": {
"sparepartrequest": "#spare_part.values"
},
"output": {
"generic": [
{
"values": [
{
"text": "You want an offer for the following parts: <?
$sparepartrequest.join(', ') ?>."
}
],
"response_type": "text",
"selection_policy": "sequential"
}
]
}
}
I have created a context variable called sparepartrequest as can be seen from the code lines above. For instance when the user says "I want an offer for a filter and a seal", the output of the bot is the following sentence:
You want an offer for the following parts: both, only_gear.
I don´t want the bot to prompt back the names of the values of the entity #spare_part, I rather want it to store the exact input of the user, for our case which would be filter and seal. So if the bot worked as I wanted it to, the output would look like the following:
You want an offer for the following parts: filter, valve.
Again, I believe that this can be handled with JSON Editor. Thank you !
Use two context variables. sparepartrequest as already done and sparepartrequest_literals as follows:
"sparepartrequest_literals":"<? entities['spare_part'].![literal].join(', ') ?>".
Then, in your text response call it by $sparepartrequest_literals to print the mentioned parts or use $sparepartrequest to refer to the detected values.
Hi I have a field in a user collection called "Address".User saving their address from a textarea in my application. mongodb convert it to new line like following.
{
"_id": ObjectId("56a9ba0ffbe0856d4f8b456d"),
"address": "HOUSE NO. 3157,\r\nSECTOR 50-D",
"pincode": "",
},
{
"_id": ObjectId("56a9ba0ffbe0856d4f8b456d"),
"address": "HOUSE NO. 3257,\r\nSECTOR 50-C",
"pincode": "",
}
So now When I am running a search query on the basis of "address".Like following:
guardianAdd = $dm->getRepository('EduStudentBundle:GuardianAddress')->findBy(array(
'address' => new \MongoRegex('/.*' .$data['address'] . '.*/i'),
'isDelete' => false
));
echo count($guardianAdd);die;
it does not give any result. My Searchi key word is : "HOUSE NO.3157 SECTOR 50-D".
However if I am searching using like: HOUSE NO. 3157 its giving correct result.
Please advice how to fix this.Thanks in advance
First of all, trailing .* are redundant. regexps /.*aaa.*/ and /aaa/ are identical and match the same pattern.
Second, you probably need to use multiline modifier /pattern/im
Finally, it is not quite clear what you want to fix. The best think you can do is to provide some basic explanation of regex syntax in the search form, so users can search properly, e.g. HOUSE NO.*3157.*SECTOR 50-D to get best results.
You can make some bold assumptions and build the pattern with something like
$pattern = implode('\W+',preg_split('/\W+/', $data['address']))
which will give you a regexp HOUSE\W+NO\W+3157\W+SECTOR\W+50\W+D for different kind of HOUSE NO.3157 SECTOR 50-D requests, but it will cut all the regex flexibility available with bare input, and eventually will result with unexpected response anyway. You can follow this slippery slope and end up with your own query DSL to compile to regex, but I doubt it can be any better or more convenient than pure regex. It will be more error prone for sure.
Asking right question to get right answers is true not only on SO, but also in your application. Unfortunately there is no general solution to search for something that people have in mind, but fail to ask. I believe that in your particular case best code is no code.
I have this data in one column in postgresql
{
"geometry":{
"status":"Point",
"coordinates":[
-122.421583,
37.795027
]
},
and i using his query
select * from students where data_json LIKE '%status%' ;
Above query return results but this one does not
select * from students where data_json LIKE '%status:%' ;
How can fix that
Of course the 2nd one doesn't find a match, there's no status: text in the value. I think you wanted:
select * from students where data_json LIKE '%"status":%'
... however, like most cases where you attempt text pattern matching on structured data this is in general a terrible idea that will bite you. Just a couple of problem examples:
{
"somekey": "the value is \"status\": true"
}
... where "status": appears as part of the text value and will match even though it shouldn't, and:
{
status : "blah"
}
where status has no quotes and a space between the quotes and colon. As far as JavaScript is concerned this is the same as "status": but it won't match.
If you're trying to find fields within json or extract fields from json, do it with a json parser. PL/V8 may be of interest, or the json libraries available for tools like pl/perl, pl/pythonu, etc. Future PostgreSQL versions will have functions to get a json key by path, test if a json value exists, etc, but 9.2 does not.
At this point you might be thinking "why don't I use regular expressions". Don't go there, you do not want to try to write a full JSON parser in regex. this blog entry is somewhat relevant.