Materials-Consortia / optimade-python-tools

Tools for implementing and consuming OPTIMADE APIs in Python
https://www.optimade.org/optimade-python-tools/
MIT License
71 stars 44 forks source link

use examples from specs as resources #57

Closed fawzi closed 5 years ago

fawzi commented 5 years ago

The current server uses mongo db and mapping of the structures stored in it because it stems from an implementation using it. I would find it simpler to simply store the structures that need to be returned in a file, and even have one file that gets them simply from the specification.

The current implementation makes it a bit cumbersome, as result it was not updated together with the update of the spec (try to get /structures for example).

I looked into doing it, and I wrote an implementation using tinydb doing that. It is a larger change so I wanted some feedback before investing time polishing it.

dwinston commented 5 years ago

Hi @fawzi, mongomock is an in-memory, all-Python implementation of the relevant aspects of the MongoDB API, and sources from simple files (see optimade/server/tests/*.json). This is sufficient as a "test" implementation that does not require any developer to install any particular database software.

I see no need to add code around Tinydb unless an optimade implementation will use it. There is a concrete MongoDB implementation because MP will use it and contribute to it (and I suspect @ml-evs will also use it, as his matador project uses MongoDB). Will NOMAD's implementation use Tinydb?

fawzi commented 5 years ago

Ok I would not use tinydb, but I think there should be an implementation where the raw examples can be used (no renames) it can be mongomock based, are you willing to do it?

dwinston commented 5 years ago

@fawzi unless I misunderstand, we already load raw examples from files such as this JSON file. What do you mean by "renames"? And yes, I am willing to ensure that mongomock can be used for all testing/prototyping, so pure Python.

CasperWA commented 5 years ago

I believe this issue is resolved: We are using mongomock and loading local JSON files from within the repository. The specification repository (or the spec itself) does not provide test structures, and as such there are none to take from other than the one provided locally here, which is completely fine. More can be added if it is felt to be necessary. Furthermore, the MongoDB part of the test server is well modularized and minimal, i.e., easily bypassed for another implementation using a separate backend.

If @fawzi or @dwinston have a problem with me closing this, please reopen and state why, or even better: Create a new issue.