Incorrect column name

[justinmcgrath]

Several tables have columns labeled "specie_id" that should be labeled "species_id".

[dlebauer]

This is a side effect of the conflict between the English language and Ruby on Rails naming conventions for tables and their unique identifiers. We have discussed in the past but have stuck with the RoR convention.

[gsrohde]

Just so as not to give RoR a bad name, this is only the Rails convention if you don't bother telling it about exceptions to pluralization rules (which it allows for). But David is right that we thought it wasn't worth the effort to correct things now.

[justinmcgrath]

I can understand how the convention is useful, but it becomes rather difficult considering the numerous nonstandard rules in English. It seems that the convention should also be to only use table names with standard plurals, e.g. species_names.

In this case, Ruby already knows about that species is an exception. carya@pecan32:~$ irb irb(main):001:0> require 'active_support/inflector' => true irb(main):002:0> 'species'.pluralize => "species" irb(main):003:0> 'species'.singularize => "species"

It is, at any rate, not a big issue, but I assume that everyone who uses this is going to wonder why things are misspelled.

[gsrohde]

"Everyone" should include only BETYdb Rails programmers. And so they should be the only ones annoyed by (as I continually am) the misnaming. Users of the BETYdb Web app should never see the column name or object attribute specie_id. Unfortunately, this name may come into play when using the URL-based query interface (otherwise known as the "API") for downloading data as a JSON, XML, or CSV file. In fact, specie_id is mentioned in several of the examples that document the use of this API (see section 3 of https://www.authorea.com/users/5574/articles/7062/_show_article); and the name specie is used there as well, in the section on cross-table queries.

Furthermore, since the BETYdb Rails code is public, users who download and run their own copies of BETYdb will see this code artifact as well, even if they aren't doing any actual Rails programming.

Since we are about to revise (or at least extend) the existing API, it may be possible to avoid using these unintuitive solecisms in the new interfaces.

It may be worth pointing out here that in general, it is highly discouraged to use any row id of any species (or any other database entity, for that matter) for any purpose other than for programming the Web application. In particular, they shouldn't be used in citations. As the API documentation emphasizes, there is no guarantee that these numbers won't change, and it is always preferable to identify an entity by some real-world characteristic—the scientific name of a species (corresponding to the column species.scientificname) for example. Any new APIs we create will likely try to avoid exposing these id numbers to the public. (They will continue to be exposed in the URLs for the pages that show or edit these entities. This is so tied in to the way that Rails works that it would be very difficult to avoid.)