Use cases for non-ID search fields in singular betydb_* functions

[infotroph]

Since all the singular BETY functions are currently set up to take one ID and return the full record if it exists, I'm not sure how the genus and species arguments are supposed to work.

Currently these all produce the same result:

betydb_specie(id=937)
betydb_specie(id=937, genus="Panicum")
betydb_specie(id=937, genus="Miscanthus")

If singular functions are changed to accept multiple IDs (see #83), then it would make sense to be able to filter the result:

betydb_specie(id=c(937, 938)) # 2 records: Panicum hemitomon, Panicum virgatum
betydb_specie(id=c(937, 938), species="virgatum") # 1 record
betydb_specie(id=c(937, 938), genus="Salix") # NULL

If singular functions continue to return strictly one or zero records, maybe there's no need to filter that one record by genus? @dlebauer am I missing something?

[infotroph]

Probably should think about this and #21 both at the same time

[dlebauer]

I am unclear on the utility of these functions are necessary. I would vote to remove them, but @sckott wrote them and perhaps there was a use case he had in mind (or for consistency with other interfaces in the package).

What would be useful is to have a function that took a vector of ids and a tablename and returned them all. So that I could do a query like betydb_query(table = 'traits', cultivar_id = c(1, 2, 3, 4, 5)). However, I'd like to come up with use cases for this first.

If there is a reason to keep these, perhaps a single function like bety_record(id = 123, table = 'tablename') would suffice?

[infotroph]

I've implemented a generic one-record function as betydb_item(id, table) in #82, but betydb_record is probably a better name for it. The other singular functions can be reimplemented as wrappers around it as the use cases arise.

Let's collect use cases for vector-of-IDs under the #83 heading.

[sckott]

i dont remember reasoning for fxns I wrote. if it makes more sense to go with something like betydb_query that's good with me. if want to remove any fxns, we'll have to mark the current fxns as deprecated (but still useable) in next CRAN version, then next ver after that we can make them defunct (removed)

[sckott]

@infotroph @dlebauer Is there anything in this issue that should be dealt with soon, like before the next CRAN push? or hold off for a while (that is, should I put it in the milestone for the next CRAN push, or on a later milestone?)

[dlebauer]

Hold off

…

On Tue, Mar 21, 2017 at 4:00 PM Scott Chamberlain ***@***.***> wrote: @infotroph <https://github.com/infotroph> @dlebauer <https://github.com/dlebauer> Is there anything in this issue that should be dealt with soon, like before the next CRAN push? or hold off for a while (that is, should I put it in the milestone for the next CRAN push, or on a later milestone?) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#84 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcX56cKi5RmKT6eJITm2qD1vyd-3udnks5roCx1gaJpZM4L4uas> .

[maelle]

This repository is about to be archived.