Models not stored about openscoring HOT 4 CLOSED

The service is stateless by design, because that makes it simpler (less moving parts), easier to use (less configuration), and applicable to a wider range of use cases (all RAM/no writeable storage runtime environments).

Why would you restart a running service anyway (other than for version upgrades)? Are you experiencing some sort of stability/resource usage issues (eg. memory leak) with it?

After restart, you are expected to populate the service with models just like you did it the first time. There should be a local filesystem directory with model PMML files somewhere, and you would simply HTTP PUT them one by one using a three-line script. For example, you could use the openscoring-python client library to abstract away REST API details.

If the restart is a scheduled event, then you might capture all models to a temporary "snapshot" directory. First, retrieve the list of models by doing HTTP GET against the model summaries endpoint /model and harvest the response object for model identifiers. Then, download models one by one in PMML data format by doing HTTP GET against the model download endpoint /model/${id}/pmml.

from openscoring.

The standalone server application (module openscoring-server) provides a --model-dir command-line configuration option, which starts a directory watchdog thread that automatically deploys and undeploys PMML files in relation to file creation and deletion events.

However, if you activate such "auto-deployment" functionality, then you shouldn't modify the state of the running service by doing "manual" HTTP PUT and DELETE operations, as these subsystems are not coordinated with one another.

from openscoring.

Linking this issue with related issues #9 and #10

from openscoring.

Thanks for your comments it's clear :-)

from openscoring.