I need some help concerning the CEP engine Esper:
I wrote the following statement:
SELECT clientID FROM MovementEvent.win:time_batch(5 sec) GROUP BY clientID
And then I sent a MovementEvent into the engine. after 5 seconds, the subscriber is triggered - ok. But after 5 more seconds, it is triggered again - why?
No matter how many events I send to the engine, the subscriber always is triggered twice - after 5 and 10 seconds
I hope you could help me!
Thanx ;)
What you need is this:
SELECT clientID FROM MovementEvent.std:groupwin(clientID).win:time_batch(5 sec);
In general, using GROUP BY without an aggregation function applied to the properties you are selecting will almost always catch you off-guard :). For the sake of it, this statement would also produce what you expected:
SELECT distinct(clientID) FROM MovementEvent.win:time_batch(5 sec);
This link will probably explain the differences better: http://www.espertech.com/esper/release-5.2.0/esper-reference/html/epl_clauses.html#epl-group-by-versus-view
The group-by makes this an aggregation and Esper provides output when there is a change in the aggregation for the keys, even if you don't select aggregations.
You could do this one
select window(*).distinctOf(v=>client) from MovementEvent.win:time_batch(5 sec)
Related
I work in a compliance role at a very small start-up and review a lot of information,for example bank transfers/direct deposits/ACHs every day. A report is pulled from BigQuery,which is exported to Google Sheets.
My question is there are a lot of false positives (basically, "posting data" that repeats often). I'm trying to eliminate it.
One idea, was just to update the query for key words:
WHERE postingdata LIKE 'PersonName%'
But it's tired and time-consuming. And I feel e there's a better way, perhaps 'filtering' the results and then feeding it back to the query. Any ideas or tips or just general thoughts?
In this case you can use group by in your query. This is how you can use this clause.
You can see this code.
SELECT account,TypeTransaction,amount,currency
FROM `tblBankTransaction`
The code returns this data, and some rows are repeated; for example, rows 1 and 7 with the account 894526972455, and it's a deposit.
In this case, I will use the group by clause.
SELECT account,TypeTransaction,amount,currency
FROM `tblBankTransaction`
group by account,TypeTransaction,amount,currency
And it returns this data:
You can see in this example that the account 894526972455 with a deposit only returns 1 row. The same account returns a second row, but is a transfer; it’s a different type of transaction. It depends on the information you have and what column you want to group.
within GS you can try UNIQUE or QUERY with group by aggregation or SORTN with mode 2 as 3rd parameter
We are measuring throughput using Grafana and Influx. Of course, we would like to measure throughput in terms how many requests, approximately, happens every single second (rps).
The typical request is:
SELECT sum("count") / 10 FROM "http_requests" GROUP BY time(10s)
But we are loosing possibility to use astonishing dynamic $__interval that very useful when graph scope is large, like a day of week. When we are changing interval we should change divider into SELECT expression.
SELECT sum("count") / $__interval FROM "http_requests" GROUP BY time($__interval)
But this approach does not work, because of empty result returns.
How to create request using dynamic $__interval for throughput measuring?
The reason you get no results is that $__interval is not a number but a string such as 10s, 1m, etc. that is understood by influxdb as a time range. So it is not possible to use it the way you are trying.
However, what you want to calculate is the mean which is available as a function in InfluxQL. The way to get the behavior that you want is with something like this.
SELECT mean("count") FROM "http_requests" GROUP BY time($__interval)
EDIT: On a second thought that is not quite what you want.
You'd probably need to use derivative. I'll come back to you on that one later.
Edit2: Do you think this answers the question that you have Calculating request per second using InfluxDB on Grafana
Edit3: Third edit's a charm.
We use your starting query and wrap it in another one as such:
SELECT sum("rps") from (SELECT sum("count") / 10 as rps FROM "http_requests" GROUP BY time(10s)) GROUP BY time($__interval)
is there a way to query for next 5 instances of given series? I am querying using time-frame:
1. ask for all the meetings for next 7 days for all user events
2. Go over each event fetched and check if event has masterSerieId
3. Return matching instances.
This feels (and is) a bit painful.
Can i request next X instances of master series right away? I can't just simply or 'simply' get them based on recurrence rule, as some might have expired.
I could image I could ask for a year ahead and pass as a query parameter masterSeriesId and limit output with $top. Is that right approach?
Based on this document, you could call /events//instances – given a start time, returns all instances in the requested time frame of the meeting specified by the provided series master ID
I have a situation where I would like to detect when a source has not sent event into the systems for more than 24 hours. When this pattern is recognized, I would like to be able to retrieve the last know event (which may be days) the source did send something. I would like this check to be done every 24 hours. I've followed the 'ATM' type example and came up with the following, pretty simple.
select a.value from pattern[every (time:interval(24 hours) and not a=Event)
This notify my update listener when 24 hour has elapsed and no event a. But how do I get previous know? I thought about using the prev or std:lastevent functions but I need a data window to select from, wasn't sure where to put that.
thanks
You could use "prior", or join in the last event like the example below shows:
select a.value, * from pattern[every (time:interval(24 hours) and not a=Event)], Event.std:lastevent()
I'm trying to find all WorkItems that were assigned to a person X in the last 30 days.
The big problem I have is the "in the last 30 days"-part.
I thought about using the "ever" or "asof" keywords, but couldn't find a good answer yet.. something like WHERE [Assigned To] = 'X' AND (([Assigned To] != 'X') asof '<30daysago>').
But this is still not a bulletproof solution.
Any better ideas?
Thanks & kind regards
Simon
It appears that this is not possible using just WIQL, but you can get close.
The keyword #Today will give you today's date, then just subtract your range from it. The EVER keyword applied to [Status]='AssignedTo' and a comparison against a date 30 days in the past to [StateChangeDate] is what you'll need to accomplish this.
As close as you can get with WIQL and existing fields:
This says, from all revisions (status changes) return records where the user 'X' has ever been AssignedTo and the State has changed in the last 30 days. This will basically give you a slightly fuzzy picture of what your User has been working on in the last month.
WHERE [Microsoft.VSTS.Common.StateChangeDate] >= #today - 30
AND [System.AssignedTo] EVER 'Bennett Aaron'
ORDER BY [System.State]
Add the missing field:
You could add a custom field called AssignedDate that is captured during the New->AssignedTo workflow transition that you create in the Work Item Definition XML. You can accomplish this using the Team Foundation Server Power Tools extension to Visual Studio. This would give you exactly what you need as well as additional reporting options going forward.
TFS API
I cannot help you with this one, but I believe you could query using the TFS API.
A couple of quick gotchas I've experienced to save you time on ASOF and EVER:
AsOf won't help you by itself with this as it does not support a range of dates. It allows you to query as if it were another date. In other words, if you forgot to capture the results of a query yesterday, you can use an AsOf query to get the results that you would have gotten had it run yesterday. What I understand is that you want to query a basic date range.
EVER might not work as you expect against dates as I believe it uses the exact value of the field (timestamp portion of the date field would be included) it tests with. Just make sure the EVER keyword is used against the status field rather than a date.