The way the metadatadeploy module typically works is that you resave all your metadata at server startup, to ensure everything is in the expected state
However we have logic built into OrderService where you’re not allowed to save (and presumably edit) an OrderFrequency if it is already in use in a concept.
I can guess at what our reasoning might have been, but…really? Is this necessary? We don’t prevent any other metadata from being changed via the API…
I have a workaround:
… so I’m not blocked by it. And I created an issue have metadatadeploy try to avoid calling save() if there are no changes:
But in general, this feels like a well-intentioned feature that has unwanted ramifications. And in general we should avoid having the underlying API place restrictions like this.
If I ever want to make a real change to an order frequency (e.g. there was a typo in the times-per-day while creating it) I will have to go do this via SQL directly in the DB.
I can see why you want to but i have never liked that approach of metadata deploy of resaving everything every time you start it regardless of whether you have made changes to an object but i will leave that aside. The primary reason why we don’t allow editing OrderFrequency is because all orders using that order frequency get affected indirectly in a way that we believed might be dangerous to the patient since some things are computed based on some fields in order frequency. The work around might be to actually just check that the 2 fields(frequencyPerDay and concept) haven’t been altered when saving an existing order frequency instead of rejecting it flat out.
@wyclif, I completely agree that having metadatadeploy resave everything
on every startup is ugly, and I hope we can fix this.
However I’m trying to make the more general point: the user interfaces we
build should be opinionated and push people to do things the right way, but
the platform API we build should not be so judgmental.
When we have business logic to block something from being done in the API
to cover the 99% use case, we have still prevented a legitimate 1% use
case. On the platform side of our work, that’s a mistake, and we should err
on the side of allowing anything to be done at the API level.
