|  | ## Object Instantiation Configuration

Introduction

Cheshire3 employs Just-in-time building of objects. This means that when a configured object is requested from its parent (usually a server or database), the parent checks whether the object has already been instantiated. If it has, then the object is simply returned, if not it is instantiated and then returned.

Once all of the objects have been configured, we need to first tell the database to build them, and then include the database into the server. The split between configuration and instantiation is an important one -- we don't want to use up memory on useless objects that will never be used.

Example

Example database configuration, continued:

    01 <config type="database" id="db_ead">
    02   <objectType>database.SimpleDatabase</objectType>
    ...
    12   <objects>
    13     <path ref="CharacterEntityPreParser"/>
    14     <path ref="eadIndexStore"/>
    15     <path ref="eadRecordStore"/>
    16     <path ref="title-idx"/>
    17     ...
    18   </objects>
    19 </config>

Example "configs.xml" configuration:

    01 <config>
    02   <paths>
    03     <path type="defaultPath">dbs</path>
    04   </paths>
    05   <subConfigs>
    06     <path type="database" id="db_dc">dbs/dc/config.xml</path>
    07     <path type="database" id="db_ead">dbs/ead/config.xml</path>
    08   </subConfigs>
    09   <objects>
    10     <path type="database" ref="db_dc"/>
    11     <path type="database" ref="db_ead"/>
    12   </objects>
    13 </config>

Explanation

At the bottom of the database configuration file is a section called objects. Here we need to give references back to the objects that we want the server to actually build at instantiation, rather than those for which it simple has a configuration and will instantiate later. This is done with a simple path element, equivalent to the way that objects that had already been instantiated are refered to in the paths section.

You may need to tell the server to build objects that you haven't defined, but have configurations included in the distribution. This isn't a problem -- you can instantiate objects at any level, so long as the server can work it's way back up the object tree to find the configuration to build it from. If the server complains (currently):

    Traceback (most recent call last):
        ...
        doc = cepp.process_document(session, doc)
    AttributeError: 'NoneType' object has no attribute 'process_document'

or similar, then it probably means that the object (in this case 'cepp') hasn't been instantiated correctly - probably because the identifer used to retrieve it was incorrect.

Once the database config.xml has been finished, you then need to include it in to the server. To do this, edit the 'configs.xml' file in the 'dbs/' directory. It should look something similar to the second example above. In this case we want to add our new 'db_ead' database, so we need to add lines 7 and 11 in red. The first is the request to include the referenced file into the configuration, and the second is to build the database object in the same way as we've just done for the objects below the database.

Now you're done with the main configuration for your database :)