Package com.ibm.fhir.persistence.jdbc.derby

Class DerbyResourceDAO

  • All Implemented Interfaces:
    FHIRDbDAO, ResourceDAO
    public class DerbyResourceDAO
extends ResourceDAOImpl
    Data access object for writing FHIR resources to an Apache Derby database.

    • Constructor Detail

      • DerbyResourceDAO

        public DerbyResourceDAO​(Connection connection,
                        String schemaName,
                        FHIRDbFlavor flavor,
                        TransactionSynchronizationRegistry trxSynchRegistry)
        Derby is not only used for unit tests, but can also be used to provide persistence for a stand-alone full FHIR server.
        Parameters:
        strat - the connection strategy
        trxSynchRegistry -

    • Method Detail

      • storeResource

        public long storeResource​(String tablePrefix,
                          List<ExtractedParameterValue> parameters,
                          String p_logical_id,
                          byte[] p_payload,
                          Timestamp p_last_updated,
                          boolean p_is_deleted,
                          String p_source_key,
                          Integer p_version,
                          Connection conn,
                          ParameterDAO parameterDao)
                   throws Exception
        Store the resource in the database, creating a new logical_resource entry if this is the first version of this resource, or creating a new resource entry if this a new version of an existing logical resource. The logic tracks closely the DB2 stored procedure implementation, including locking of the logical_resource and handling concurrency issues using the standard insert-or-update pattern: 
           SELECT FOR UPDATE                 -- try and get a write lock
   IF NOT FOUND THEN                 -- doesn't exist, so we don't have a lock
     INSERT new logical resource     -- create the record - if OK, we own the lock
     IF DUPLICATE THEN               -- someone else beat us to the create
       SELECT FOR UPDATE             -- so we need to try again for a write lock
     ...
   ...
        This works because we never delete a logical_resource record, and so don't have to deal with concurrency issues caused when deletes are mingled with inserts/updates Note the execution flow aligns very closely with the DB2 stored procedure implementation (fhir-persistence-schema/src/main/resources/add_any_resource.sql)
        Parameters:
        tablePrefix -
        parameters -
        p_logical_id -
        p_payload -
        p_last_updated -
        p_is_deleted -
        p_source_key -
        p_version -
        Returns:
        the resource_id for the entry we created
        Throws:
        Exception

      • deleteFromParameterTable

        protected void deleteFromParameterTable​(Connection conn,
                                        String tableName,
                                        long logicalResourceId)
                                 throws SQLException
        Delete all parameters for the given resourceId from the parameters table
        Parameters:
        conn -
        tableName -
        logicalResourceId -
        Throws:
        SQLException

      • getResourceTypeId

        protected Integer getResourceTypeId​(String resourceTypeName,
                                    Connection conn)
                             throws SQLException
        Read the id for the named type
        Parameters:
        resourceTypeName -
        Returns:
        the database id, or null if the named record is not found
        Throws:
        SQLException

      • getOrCreateResourceType

        public int getOrCreateResourceType​(String resourceTypeName,
                                   Connection conn)
                            throws SQLException
        stored-procedure-less implementation for managing the resource_types table
        Parameters:
        resourceTypeName -
        Throws:
        SQLException