Delete OPT template

[johnmeredith]

We have hit a snag with a previous template and now get a 409 conflict error. Ideally we would delete the incorrect template in this case and re-upload but this is not possible with the current API. How can this be achieved?

[freshehr]

Basically I think that Ehrbase prevents the re-post of a template with the same templateId and uid with a Conflict error, which I read as being correct, from the specs.

However updating a template is a pretty common and necessary activity particularly in early stages of design, and the Better openEHR REST implementation does not generate a Conflict error.

So either we need to add a PUT ( or loosen the spec) or …?

[birgerhaarbrandt]

I actually could have sworn that we also added a delete endpoint but I might confuse this with stored queries. This is surely something that we should put on our short-term roadmap...

[freshehr]

I've opened the conversation in the SEC group as arguably the spec is too tight for a design phase. There is no Delete in the openEHR spec - deliberately - as it was felt to be a back office function and potentially catastrophic on a working system. One suggestion has been that the strict 'conflict' should not apply to V0 templates. We actually need to pin down template versioning behaviour. It ight be worth a chat with th e Better folks as to why they did not implement the 'conflict' as per the spec.

[stefanspiska]

@johnmeredith
Right now the only way to delete a template is via the DB.
Stop ehrbase
Run via SQL in the Postgres DB
delete from ehr.template_store s where s.template_id = ?
Start ehrbase and re-upload the template

[freshehr]

Thanks @stefanspiska that will work but I'd prefer not to be messing around directly on the db. I'm not so bothered by the lack of DELETE, as long as we can overwrite an existing template, at least in demo mode. In a typical training session, I would be building a template uploading it, changing it (non-breaking change), re-uploading it, showing the change.

My suggestion is that this specification should be relaxed, perhaps optionally for test/demo environments. This is what Better appear to have done.

We can be much smarter in terms of using semver to detect breaking changes, or warn of non-breaking changes but right now this is a pain, due to the specs being a little too unforgiving - not your fault!

[stefanspiska]

with 126dd2b
There is now a spring property
system.allow-template-overwrite
which if set to true allows to overwrite an existing template.