search

sckott / usdaplantsapi

DEFUNCT - REST API for the USDA Plants Database
MIT License
105 stars 9 forks source link

Keep syntax consistent with original database? #7

Closed dlebauer closed 4 years ago

dlebauer commented 8 years ago

I noticed in the latest version names have been converted from CamelCase to Camel_Pothole_Case, e.g. AcceptedSymbol to Accepted_Symbol

and

It looks like a join has appended _x and _y to some of these names (e.g. Accepted_Symbol_x and Accepted_Symbol_y)

One side effect of this is that your example curl 'https://plantsdb.xyz/search?limit=2&fields=Genus,Species,AcceptedSymbol' | jq . (in the README) is broken (should be Accepted_Symbol_x

dlebauer commented 8 years ago

PS I'd suggest keeping style consistent with the source database to facilitate interoperability

sckott commented 8 years ago

The .x and .y versions are definitely from a join, but since they were there already I didn't know how to rename the .y versions. Do I just remove the .y versions?

I can convert back to CamelCase

dlebauer commented 8 years ago

Sorry didn't realize that was my work! Yes drop the .y versions.

The original USDA names have a few potholes, not pure CamelCase - the goal is consistency rather than style. On Tue, Jul 12, 2016 at 6:42 PM Scott Chamberlain notifications@github.com wrote:

The .x and .y versions are definitely from a join, but since they were there already I didn't know how to rename the .y versions. Do I just remove the .y versions?

I can convert back to CamelCase

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sckott/usdaplantsapi/issues/7#issuecomment-232214402, or mute the thread https://github.com/notifications/unsubscribe/AAcX5-ofBaHPy4puo-DcMQGWzOxVc8YJks5qVCZogaJpZM4JK62n .

sckott commented 8 years ago

But keep the joined columns to the right of the columns with .y versions, correct?

dlebauer commented 8 years ago

yep - keep joined columns to the right. They are sparse - only 3% of the rows have any information (from http://plants.usda.gov/charinfo.html) - "2000 conservation plant species and 500 additional cultivar".

If speed or optimization is an issue, you could reduce the size by either a) keeping the tables separate and joining on the fly or b) not returning values that are "".

sckott commented 8 years ago

I might make a separate table for the other columns.

also, returning "" isn't ideal, meaning to change all those to null but haven't sorted out fastest way to do that yet

I might play with not returning fields with no data, though that makes merging records a bit more complicated

dlebauer commented 8 years ago

@sckott regarding Syntax - I just checked and now see that they don't use camel case but white space. Seems reasonable that useability should trump consistency so go with the potholes.