I would say that ‘hiding patients from users that are not supposed to see them’ is in fact the primary goal of the Data Filter module. Therefore it can also be leveraged to achieve multi-tenancy, but that was not its primary intent. Anyway this is why I mentioned it. It uses Hibernate filters under the hood btw.
Whether one can achieve the data segregation that is demanded by a given business case will be up to each implementation’s configuration that is fed to the module. It would be great is if you could test it for multi-tenancy when it is a little more ready. So if the above seems to fit your end goal as well, I’d be more than happy to keep you in the loop. We’re planning a POC demo either next week or the week after.
Cc @snehabagri @wyclif @lilian
And I am not saying that we shouldn’t pursue other types of multi-tenancy strategies such as the spike that you’ve done (
) , just trying to join forces wherever possible.
My quick thinking on this is that IF the ‘one database-multiple schema’ strategy could work (and my understanding is that you’re not sure yet that this would improve the situation) then we should aim at providing support for Postgres. It hinges on your remark:
Even when this works (Postgres, H2), you still have to create the tables one at a time for each schema, so it doesn’t seem to give much improvement.
I have no idea, but if there is a chance that there is an acceptable performance hit with Postgres when running Liquibase changesets… etc over multiple schemas, then this is the way IMO.