list_requests questions

[steffilazerte]

I've implemented a basic call to list_requests (nc_requests()) and have a couple of questions:

1. What is requestLabel vs. requestOrigin? Just a prettier/human-readable version?
2. Are the expected statuses "yes" vs. "no" in the 'approved' column? Just checking as the API documentation makes reference to available vs. pending.
3. I can retrieve the request information for the example token provided in the index.html, but if I successfully initiate and complete a download with my own username, then look at the requests for that token, no requests are logged (that I can see), is this expected?

[pmorrill]

1. requestLabel is something we collect on the web forms (but in the api I just supply a standard label right now). It's just a label string the user supplies. requestOrigin is always one of three values [web|api|mixed]

2. The status provided by the list_requests call should be 'approved' vs 'pending' - I'll look into that

3. What is your user id? Do you know? I can look into this: you should be seeing requests as long as you actually downloaded data.....

[steffilazerte]

Got it working! Another thing to think about: how many requests do you want to save? I use the 'sample' user to run unit tests, so they will accumulate pretty quickly!

[denislepage]

If this is an issue, we could make some exceptions to avoid saving the requests made by the sample account, but the data flow may require it been saved between calls?

[pmorrill]

Yes - I think we will have to make an exception for the sample account. I am not here tomorrow, but can look into it next week.

[pmorrill]

The caching is only in local memory between calls, so we can set up a rule to skip the final save (which is when it gets put into the database)

[steffilazerte]

Could we also make columns returned from list_collections and list_requests have consistent column names? In the R client I use these two entry points in a similar fashion, depending on whether a requestId has been provided or not, so it'd be helpful to have them return similar output. I can easily make the changes locally, but I thought it might be better to be consistent in the API anyway?

Right now list_collections returns collection and nrecords whereas list_requests returns collections and recordCount (among others).

[steffilazerte]

What about identical requests? If a particular user submits a request for the exact same filters, currently, a new requestId is created each time. Would it be worth/possible to check against previous requests? Is this something that the R client should do?

I'm assuming that the requestId stores a particular filter set (and not the exact record_ids which are returned by the filter set).

[pmorrill]

Checking a new request against previous requests is possible..... but I am not sure how involved. For now, my feeling is that we continue to generate new DateRequests records for each new request, but that we encourage users to use previously stored requests where possible.

One thing that we do not allow when using prior requests is adding any new collections: if the user did not query on a specific collection when the request was generated, s/he will not be able to do so later either.

We also do not allow the user to specify a label for queries generated by the api, though this might be useful. For example, we could allow that parameter as part of the 'release_request_id function (which is where the record is actually cut to the database).

[steffilazerte]

My responses in order to your three points (nothing much to say, really):

1. I could have the R client do the check for identical requests, if that turns out to be useful. For now I'll put on the "to think about" list.
2. That makes sense, collections are just another filter option, really.
3. I'm not sure how helpful this would be on the R side, but definitely something to consider.

[denislepage]

I like the idea of being able to give a name to the request. This is available for web requests, and may help users or managers identify their requests. I use the date (I'd have to check the exact format) by default in absence of name.

[pmorrill]

I have updated the following:

1. in the list_requests return, now using 'collection' and 'nrecord'

2. in the list_requests return, status is now 'approved' or 'pending'

3. In the list_collections return, access field is not included unless token is present

[pmorrill]

For the 'release_request_id' function, I have added support for a 'label' parameter: if provided, this string will be set as the request_label in the database record.

[denislepage]

For status, you will also encounter cases of rejected (declined is better) and ignored (same as declined)

-------- Original message -------- From: pmorrill notifications@github.com Date: 5/23/19 23:24 (GMT+09:00) To: BirdStudiesCanada/NatureCountsAPI NatureCountsAPI@noreply.github.com Cc: Denis Lepage dlepage@birdscanada.org, Comment comment@noreply.github.com Subject: Re: [BirdStudiesCanada/NatureCountsAPI] list_requests questions (#24)

I have updated the following:

1. in the list_requests return, now using 'collection' and 'nrecord'

2. in the list_requests return, status is now 'approved' or 'pending'

3. In the list_collections return, access field is not included unless token is present

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/BirdStudiesCanada/NatureCountsAPI/issues/24?email_source=notifications&email_token=AFBB6DQTBYSGQMY7BRZS4C3PW2SKBA5CNFSM4HL4JRAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWCMO6I#issuecomment-495241081, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFBB6DRRUXL3KJXJAB4MPDLPW2SKBANCNFSM4HL4JRAA.