StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
18689516
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2013-09-08T23:05:56.993
FavoriteCount
0
LastActivityDate
2015-02-05T11:33:46.140
LastEditDate
2015-02-05T11:33:46.140
LastEditorUserId
793002
OwnerUserId
650630
ParentId
18688831
PostTypeId
2
Score
2
ViewCount
0
LastEditorDisplayName
text
Body
There are several issues to think about here - is there going to be a single process using your API key at any one time, or is it possible that multiple processes would be running at once? If you have multiple <code>delayed_job</code> workers, I think the latter is likely. I haven't used <code>delayed_jobs</code> enough to give you a good solution to that, but my feeling is you would be restricted to a single worker. I am currently working on a similar problem with an API with a restriction of 1 request every 0.5 seconds, with a maximum of 1000 per day. I haven't worked out how I want to track the per-day usage yet, but I've handled the per-second restriction using threads. If you can frame the restriction as "1 request every 0.2 seconds", that might free you up from having to track it on a minute-by-minute basis (though you still have the issue of how to keep track multiple workers). The basic idea is that I have an request method that splits a single request into a queue of request parameters (based on the maximum number of objects allowed per request by the api), and then another method iterates over that queue and calls a block which sends the actual request to the remote server. Something like this: <pre><code>def make_multiple_requests(queue, &block) result = [] queue.each do |request| timer = Thread.new { sleep REQUEST_INTERVAL } execution = Thread.new { result << yield(request) } [timer, execution].each(&:join) end result end </code></pre> To use it: <pre><code>make_multiple_requests(queue) do |request| your_request_method_goes_here(request) end </code></pre> The main benefit here is that if a request takes longer than the allowed interval, you don't have to wait around for the <code>sleep</code> to finish, and you can start your next request right away. It just guarantees that the next request won't start until at least the interval has passed. I've noticed that even though the interval is set correctly, I occasionally get an 'over-quota' response from the API. In those cases, the request is retried after the appropriate interval has passed.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POQueuing API calls to fit rate limit
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USAdrien Coquio
UserOwnerUserId
1. USZach Kemp
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.