Conversation
|
Did you want this to be a draft PR? It cannot be merged while it's in that state. |
|
By the way, I'm not sure I fully understood what you were proposing to do with the snowflake ids and time, that is really very cool. |
|
Yeah - i'm still working on making the progress bar output more interpretable, and adding progress bars to other commands (like The snowflake -> timestamp trick gets around the issue of not knowing how many tweets there are but knowing the time span processed - those functions will also come in for #459 |
|
So, there's now a The |
|
The fancier output for search progress bar also introduces a new dependency, |
|
The new progress bar is BEAUTIFUL -- much more readable. I like how |
|
Just fixing a few more things - disambiguating and filling in defaults when using |
|
It seems to me like this is ready to be merged/deployed? |
|
Not yet unfortunately - i found some more weirdness with |
|
Slightly better again - here are the test cases i'm using: ( search (snowflake timestamp) flatten (input file) users (input file) hydrate (input file) mentions (manual count - API limit of 800) conversation (snowflake timestamp) conversations (input file) timeline (timestamp or manual count) timelines (input file) following (count using user lookup) followers (count using user lookup) |
|
Ok, maybe now it's good to go. This turned out to be way bigger than i expected. |
fixes #437, fixes #289
I think i got it to work how i wanted, but the missing part is a better display for the items /sec and current total. There's probably a better way of doing that that i'm still trying to figure out.
This only adds a progress bar to the search endpoint as an example - i'll add them to other commands if this one looks good.
Commands with progress bars:
Commands with
--limitterminate the progress bar early - i think this is a good visual clue as to what's happening.