Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

data lifetime #16

Open
kvlahromei opened this issue Mar 3, 2015 · 1 comment
Open

data lifetime #16

kvlahromei opened this issue Mar 3, 2015 · 1 comment

Comments

@kvlahromei
Copy link
Contributor

Think about an server offering the API for a period of time. During the months/years it's getting obvious, that the configuration/scenario of the operator will change and he needs to add or change e.g. service definitions, service name or codes.

Are there any speficications how we expect that the API will deal with that?
Do we suggest to present data as "snapshots" (keep values as the were while editing the data) or do we expect to present consistent data as 'live view' ?
What we suggest about migration and backwards compability of data?

@philipashlock
Copy link
Member

If I understand the question correctly, you're asking about the fact that a service definition might change over time and no longer match some of the historical service requests that had been generated using that definition. Is that correct?

I don't think this is something that has received much discussion. Perhaps there could be some what to retain a version history of the service definitions or maybe we just try to ensure there's enough context available stored within the service request that we can make sense of it even if the original service definition is no longer available. This also points to another unresolved issue which is that the specification doesn't explain how custom parameters defined by a service definition are stored with the service request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants