I have a Google project created on the Google developer console. This project retrieves information about all content on my channel (livestreams and posted videos) and keeps statistics updated for each one. The processes that gather this information run three times per day. I would like to run them more frequently, but after a total of 300 quota, I receive the dreaded error 403 that says,
The request cannot be completed because you have exceeded your quota
Here is a today's usage summary as an example:
+------------+---------------------------------------------+------------------------------------+-------+-----------+--------+
| callDate | calledBy | serviceName | calls | totalCost | failed |
+------------+---------------------------------------------+------------------------------------+-------+-----------+--------+
| 2022-04-14 | /www/htdocs/GetChats/someoneSingsVideos.php | search->listSearch | 53 | 106 | 3 |
| 2022-04-14 | /www/htdocs/GetChats/someoneSingsVideos.php | videos->listVideos | 50 | 50 | NULL |
| 2022-04-14 | /www/htdocs/GetChats/lives.php | liveBroadcasts->listLiveBroadcasts | 10 | 10 | NULL |
| 2022-04-14 | /www/htdocs/GetChats/videos.php | search->listSearch | 48 | 96 | NULL |
| 2022-04-14 | /www/htdocs/GetChats/videos.php | videos->listVideos | 48 | 48 | NULL |
| 2022-04-14 | /www/htdocs/GetChats/someoneSingsVideos.php | --program total-- | 103 | 156 | 3 |
| 2022-04-14 | /www/htdocs/GetChats/lives.php | --program total-- | 10 | 10 | NULL |
| 2022-04-14 | /www/htdocs/GetChats/videos.php | --program total-- | 96 | 144 | NULL |
| 2022-04-14 | --day total-- | | 209 | 310 | 3 |
+------------+---------------------------------------------+------------------------------------+-------+-----------+--------+
So in essence, I can get about 50 searches and about 100 list calls done in a day... then I have to wait 24 hours to try again. But when I check my quotas and their usage at the IAM Admin Quotas page, I see a very different result:
This page, intended to clarify API Quotas and their usage, just adds questions for me. For example, at face value, looks like there is a 10,000 quota-units limit per day but I can do 1.8M per minute. Clearly both cannot be true. But morr to the point, it seems to indicate that i'm way below my legal limit although it issues that error and stops me until the next day, after that 300 quota is reached.
Can anyone help me understand what the real limits are, and maybe help me understand why I must keep my usage so low?
Related
I have a model for user activity history
I also store today's information in the Redis database.
At a specific time, the Redis information is stored in the history model and there is no need to call the Redis information.
In the history model, there is one history for each user per day.
I need when the history model is called, along with that data today as the last record.
Until this information enters the history model.
Is it possible to define these in the model?
Or should each user receive and merge today's information after receiving the history information?
userHistoryModel:
user_id | date | activity | otherData1| otherData2
-----------+--------------+----------+---------- +----------
1 | 2021-08-01 | 9693.00 | 9523.00 | 1
2 | 2021-08-01 | 9320.00 | 9341.00 | 2
3 | 2021-08-01 | 9321.00 | 92245.00 | 3
1 | 2021-08-02 | 9320.00 | 9412.00 | 4
2 | 2021-08-02 | 9320.00 | 9325.00 | 5
1 | 2021-08-03 | 45623.00 | 45550.00 | 1
2 | 2021-08-03 | 47725.00 | 48500.00 | 2
3 | 2021-08-03 | 49448.00 | 49787.00 | 3
2 | 2021-08-04 | 48768.00 | 46251.00 | 4
3 | 2021-08-04 | 49800.00 | 41254.00 | 5
3 | 2021-08-05 | 623.00 | 854.00 | 1
RedisHash:user:1
--------------+--------------
user_id | 1
date | 2021-08-01
activity | 7485.25
otherData1 | 87484.87
otherData2 | 7
I'm considering whether I should format a table in my sqlite database in "wide or "long" format. Examples of these formats are included at the end of the question.
I anticipate that the majority of my requests will be of the form:
SELECT * FROM table
WHERE
series in (series1, series100);
or the analog for selecting by columns in wide format.
I also anticipate that there will be a large number of columns, even enough to need to increase the column limit.
Are there any general guidelines for selecting a table layout that will optimize query performance for this sort of case?
(Examples of each)
"Wide" format:
| date | series1 | series2 | ... | seriesN |
| ---------- | ------- | ------- | ---- | ------- |
| "1/1/1900" | 15 | 24 | 43 | 23 |
| "1/2/1900" | 15 | null | null | 23 |
| ... | 15 | null | null | 23 |
| "1/2/2019" | 12 | 12 | 4 | null |
"Long" format:
| date | series | value |
| ---------- | ------- | ----- |
| "1/1/1900" | series1 | 15 |
| "1/2/1900" | series1 | 15 |
| ... | series1 | 43 |
| "1/2/2019" | series1 | 12 |
| "1/1/1900" | series2 | 15 |
| "1/2/1900" | series2 | 15 |
| ... | series2 | 43 |
| "1/2/2019" | series2 | 12 |
| ... | ... | ... |
| "1/1/1900" | seriesN | 15 |
| "1/2/1900" | seriesN | 15 |
| ... | seriesN | 43 |
| "1/2/2019" | seriesN | 12 |
The "long" format is the preferred way to go here, for so many reasons. First, if you use the "wide" format and there is ever a need to add more series, then you would have to add new columns to the database table. While this is not too much of a hassle, in general once you put a schema into production, you want to avoid further schema changes.
Second, the "long" format makes reporting and querying much easier. For example, suppose you wanted to get a count of rows/data points for each series. Then you would only need something like:
SELECT series, COUNT(*) AS cnt
FROM yourTable
GROUP BY series;
To get this report with the "wide" format, you would need a lot more code, and it would be as verbose as your sample data above.
The thing to keep in mind here is that SQL databases are built to operate on sets of records (read: across rows). They can also process things column wise, but they are not generally setup to do this.
I am creating a BIRT Report where each row is a receipt matched with a purchase order. There are usually more than one receipt per purchase order. My client wants the qty_remaining on the purchase order to show only on the last receipt for each purchase order. I am not able to alter the data before BIRT gets it. I see two possible solutions, but I am unable to find how to implement either. This question will deal with first possible solution.
If I can compare the purchase order number(po_number) with the next row, then I can set the current row's qty_remaining to 0 if the po_numbers match else show the actual qty_remaining. Is it possible to access the next row?
Edit
The desired look is similar to this:
| date | receipt_number | po_number | qty_remaining | qty_received |
|------|----------------|-----------|---------------|--------------|
| 4/9 | 723 | 6026 | 0 | 985 |
| 4/9 | 758 | 6026 | 2 | 1 |
| 4/20 | 790 | 7070 | 58 | 0 |
| 4/21 | 801 | 833 | 600 | 0 |
But I'm currently getting this:
| date | receipt_number | po_number | qty_remaining | qty_received |
|------|----------------|-----------|---------------|--------------|
| 4/9 | 723 | 6026 | 2 | 985 |
| 4/9 | 758 | 6026 | 2 | 1 |
| 4/20 | 790 | 7070 | 58 | 0 |
| 4/21 | 801 | 833 | 600 | 0 |
I think you looking at this the wrong way. If you want behavior that resembles for loops you should use grouping and aggregate functions. You can build quite complex stuff by using (or not using) the group headers and footers.
In your case I would try to group the receipts on po_number. Order them by receipt_number then have a aggregate function like MAX or LAST on the receipts_number and name it 'last_receipt'. It should aggregate on the group, not the whole table. This 'total' is available on every row within the group.
Then you can use the visibitly setting to only show the qty_remaining when the row['receipt_number'] == row['last_receipt']
I have created a bus transit application for a city in windows phone 8. I have stored all my routes and bus stops in a separate table in the database.
My bus stop table contains:
stop_id | stop_name | latitude | longitude | status | alias_name
---------------------------------------------------------------------------------------
1736 | Atlas Company | 18.629243 | 73.833814 | Active | Centurenca Corner
1737 | Atlas company | 18.629243 | 73.833814 | Active |
681 | Atma Anand Dhyan Kendra | 18.600349 | 73.926251 | InActive |
My Routes Table contains
bus_id | bus_no | bus_source | bus_destination | days_of_week | total_distance estimated_time | source_stop_names | destination_stop_names | total_stops | source_trip_time | destination_trip_time | bus_status
source_stop_names contains
-----------------
1 | Swargate
2 | Parvati payatha
3 | Dandekar pul
4 | Pan mala Sinhgad Road
5 | Jal Shuddhikarn Kendra Sinhgad Road
6 | Ganesh mala
7 | Vitbhatti Sinhgad Road
8 | Vitthalwadi jakat naka
9 | Jaydeo nagar
10 | Rajaram pul
11 | Vitthalwadi Mandir Hingne
12 | Hingne rasta
13 | Anand nagar singhgad rd
14 | Manik Bag
15 | Indian hum company
16 | Wadgaon phata
17 | Patil colony
18 | Dhayari phata
19 | Sanas Vidyalaya
20 | Dangat wasti
21 | Gar mala
22 | Dhayarai gaon
23 | Raykar wasti
24 | Poultry farm singhgad road
25 | Dhayarigaon shala
26 | Chavan mala
27 | DSK Vishwa
I want to find the shortest path between two bus stops not connected by a bus route, and show the number of routes and buses the user has to take while travelling from one point to another, like google maps does.
I have used default map control in windows phone 8.
In reading RFC 4733, it doesn't clearly state whether the event duration should not increment in the final 3 e-bits. It seems the important information in the event is the m-bit, timestamp, and e-bit. If the event duration does increment in the final 3 e-bits, would it make sense to consider each of the 3 e-bits as seperate events and triplicate the tones? Or should the first e-bit received be the end of the event and the last 2 ebits be disgarded? I have a wireshark capture that shows the event duration incrementing in the 3 ebits and I am tyring to make sense of this.
Given that the final packet of the event may be transmitted three times, the duration field should monotonically increase. In the discussion in the comments we thus see three packets, each with the E bit set, and durations of 720, 800 and 880. This indicates that the packets are sent 80ms apart, because the duration field in the packet indicates that the event "has so far lasted as long as indicated by this parameter".
However, it's still a single event, so your playout of the event should last for the duration of the first packet you receive.
For example, you're seeing three packets arrive, but if the first packet (with duration 720) didn't arrive, you'd see the second packet (with duration 800), and you should play the tone for 800ms.
That said, I'd expect the sender to send the end packet with the same duration, rather than what you're seeing. That might be a bug in the sender. (Transmission must cause an increment in duration, but this is retransmission.)
The sender is clearly breaking the RFC since
the 'E' bit should be set when the event has ended
the duration is increased according to the duration of the event
If the duration is still increasing then clearly the event has not ended but if the E bit was set the event has ended - i.e. contradiction
On the other hand (from 2.5.2.2)
once the receiver has received the end of the event it should stop playing the tone.
A receiver SHOULD NOT restart a tone once playout has stopped.
The receiver MAY determine on the basis of retained history and the timestamp and event code of the current packet that it corresponds to an event already played out and lapsed. In that case, further reports for the event MUST be ignored
i.e. You can tell that the event has already played out from the timestamp and should not repeat the event in this case
The example in the RFC 4733 is given in Table 5
https://datatracker.ietf.org/doc/rfc4733/
+-------+-----------+------+--------+------+--------+--------+------+
| Time | Event | M | Time- | Seq | Event | Dura- | E |
| (ms) | | bit | stamp | No | Code | tion | bit |
+-------+-----------+------+--------+------+--------+--------+------+
| 0 | "9" | | | | | | |
| | starts | | | | | | |
| 50 | RTP | "1" | 0 | 1 | 9 | 400 | "0" |
| | packet 1 | | | | | | |
| | sent | | | | | | |
| 100 | RTP | "0" | 0 | 2 | 9 | 800 | "0" |
| | packet 2 | | | | | | |
| | sent | | | | | | |
| 150 | RTP | "0" | 0 | 3 | 9 | 1200 | "0" |
| | packet 3 | | | | | | |
| | sent | | | | | | |
| 200 | RTP | "0" | 0 | 4 | 9 | 1600 | "0" |
| | packet 4 | | | | | | |
| | sent | | | | | | |
| 200 | "9" ends | | | | | | |
| 250 | RTP | "0" | 0 | 5 | 9 | 1600 | "1" |
| | packet 4 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 300 | RTP | "0" | 0 | 6 | 9 | 1600 | "1" |
| | packet 4 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
If you look at the last 2, you see they both have the "E" bit set, and that the duration is set to 1600 (8000 * 200/1000).
I hope that helps!