Consistency in the number of records calculated

[steffilazerte]

In my forays into claifying access for users, I've run into the following sources of inconsistency/confusion:

Inconsistent naming

• data/list_collections returns nrecords
• data/list_requests returns nrecords
• metadata/collections returns n_records

Inconsistent values
In some collections nrecords returned by the data/list_collections are greater than the n_records returned by metadata/collections. Is this deliberate, or a problem?

Collections where this is the case: BCCWS, CMMN-LPBO-MOBU, PRISM-ACSS, PRISM-OSS, SWIFTWATCH

[denislepage]

Might be useful to fix name inconsistency, yes.

In theory, the counts are being synchronized as new data gets added, as well as something like weekly.

When possible, a full collection count is easier/faster to get from the metadata table. That can’t easily be done however when any filters are applied.

The solution would to ensure that the metadata is consistent, and plug the cracks that allows them not to be.

[pmorrill]

Inconsistent naming

data/list_collections returns nrecords

data/list_requests returns nrecords

metadata/collections returns n_records

The 'n_records' field name comes directly out of the table, via prAPI_collections. It is odd-man-out in the above so maybe we should just update the proc with an alias for that field?

But I notice that 'api/data/get_data' returns an attribute 'records'. Do you want me to change that to nrecords?