From 35fbe69589dd82200d3bae44e26e0fb95930fe17 Mon Sep 17 00:00:00 2001 From: Jafer Khan Date: Wed, 25 Dec 2019 20:31:57 +0500 Subject: [PATCH] Add more text to the incomplete paragraph. Fixes gh-1638 --- .../resources/ca/uhn/hapi/fhir/docs/server_jpa/architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hapi-fhir-docs/src/main/resources/ca/uhn/hapi/fhir/docs/server_jpa/architecture.md b/hapi-fhir-docs/src/main/resources/ca/uhn/hapi/fhir/docs/server_jpa/architecture.md index cb53fef461c..89dd4a17a7f 100644 --- a/hapi-fhir-docs/src/main/resources/ca/uhn/hapi/fhir/docs/server_jpa/architecture.md +++ b/hapi-fhir-docs/src/main/resources/ca/uhn/hapi/fhir/docs/server_jpa/architecture.md @@ -18,5 +18,5 @@ The HAPI JPA Server has the following components: # Schema -This implementation uses a fairly simple table design, with a single table being used to hold resource bodies (which are stored as CLOBs, optionally GZipped to save space) and a set of tables to hold search indexes, tags, history details, etc. This design has proven to be very scalable and flexible, and has been successfully used in large scale production architectures. That said, +This implementation uses a fairly simple table design, with a single table being used to hold resource bodies (which are stored as CLOBs, optionally GZipped to save space) and a set of tables to hold search indexes, tags, history details, etc. This design has proven to be very scalable and flexible, and has been successfully used in large scale production architectures. That said, this design is still only one of many possible ways of designing a FHIR server so it is worth considering whether it is appropriate for the problem you are trying to solve.