search

OpenTreeOfLife / treemachine

Source tree graph database
Other
16 stars 6 forks source link

Bad property value for was_constrained and was_uncontested #216

Closed jar398 closed 8 years ago

jar398 commented 8 years ago

The value is {} instead of a boolean. It is documented to be a boolean here.

E.g.

curl -X POST https://devapi.opentreeoflife.org/v3/tree_of_life/node_info -H "content-type:application/json" -d '{"node_id":"ott396446","include_lineage": true}'

I would actually prefer that these fields be suppressed altogether, temporarily, since the API documentation is already under review and doesn't mention them. But after review (do they need to occur in every node, or can they default to true or false, etc.) we will probably document them and put them back in.

josephwb commented 8 years ago

i had no idea that a new property was going to be involved in the new annotations, or would have made sure that it works.

jar398 commented 8 years ago

Yes, I understand.

To insulate treemachine against other propinquity vagaries, I've modified getSynthMetadataAndUniqueSources to only transfer properties that belong to an approved set. So we should be OK even if even more stuff gets added that we don't anticipate.

This is in the v3 branch and running on devapi.

josephwb commented 8 years ago

Ok, so I don't have to do anything? On ingest everything has been expected to be a string (or can be converted to a string).

jar398 commented 8 years ago

You don't have to do anything. (issue closed generally means nobody has to do anything more on it.)