You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As long as we're using this "client" model, one of these clients is going to have to have an interface that our scraper knows about and can use to access a current snapshot of the database.
This should be the v2 API.
The text was updated successfully, but these errors were encountered:
bepetersn
changed the title
specify a client to act as database snapshot for scraper
specify v2 API as the read-client database for the scraper
May 21, 2014
This actually does not need to be done anymore. My understanding is the scraper will just post the raw inmate data, and the v2 API can figure out the rest. No need for the scraper to know anything about any database.
I am agree. The scraper will not be dependent on any database. This is a
great example of seperation of concerns. Capturing the basic inmate
information and making it available versus processing the data for analysis
and supporting quering on the processed data are separate and distinct
activities.
Norbert
On Jun 6, 2014 1:26 PM, "Brian Everett Peterson" [email protected]
wrote:
This actually does not need to be done anymore. My understanding is the
scraper will just post the raw inmate data, and the v2 API can figure out
the rest. No need for the scraper to know anything about any database.
—
Reply to this email directly or view it on GitHub #391 (comment).
As long as we're using this "client" model, one of these clients is going to have to have an interface that our scraper knows about and can use to access a current snapshot of the database.
This should be the v2 API.
The text was updated successfully, but these errors were encountered: