Page History

...

Implementation Example and Discussion

Call the super constructor

...

Looking at the implementation of this interface in lbImpl, org.LexGrid.LexBIG.Impl.loaders.MedDRALoaderImpl, notice that implementation is kept relatively clean thanks to the fact that much of the mechanism of loading into LexEVS is taken care of under the covers by the BaseLoader class.  It   MedDRALoaderImpl creates a constructor that always calls the BaseLoader constructor, then prevents the use of manifests.  (If you wish you may choose to allow manifest use, since it allows load time manipulation of coding scheme metadata.  Often source files do not provide all that needs to be known about the source.  A manifest file allows values that may not be present in the source, such as copyrights, authoring information, version definition and formal coding scheme name to be added to the load.)

...

In order to get loading done theory the developer could at this point implement only doLoad by mapping content to a coding scheme object and persisting it before turning control over to BaseLoader which will call the doLoad method and set default load options in its load method and kick off the processes to persist a coding scheme object to the database.  The other option is to implement doLoad and override the load method which sets up end user option choices for the loader.   Most loaders implement the load method, customizing load options to provide to the end user.  In the case of the MedDRA loader, a CUI load option is provided to the end user.

Less Structure Beyond the Loader, BaseLoader Implementation and Extension

Beyond these methods, the structuring of code is largely and necessarily left up to the developer.  However a few common patterns are fairly consistent in this implementation.  Generally speaking, there is a central mapping class where the coding scheme object creation is builtkicked off.      Other classes, when necessary, are supportive to this central class. 

These classes are generally classified by those that are responsible for either reading a source file or accessing an API that reads the file for you and those that map objects created from that file into LexEVS coding scheme metadata, entity and relationship objects.  A third category will include accessing LexEVS persistence mechanisms and passing these values to the database. 

In the lbConverter project  the edu.mayo.informatics.lexgrid.convert.directConversions.medDRA package contains the classes that do much of the work of the MedDRA load into LexGrid.  edu.mayo.informatics.lexgrid.convert.directConversions.medDRA.MedDRA2LGMain provides a central kickoff point with some methods that can be wrapped for load and validation responsibilities down further up the execution chain. This package also contains edu.mayo.informatics.lexgrid.convert.directConversions.medDRA.MedDRAMapToLexGrid with a readMedDRAFile that reads data from a CSV file and persists it to objects defined in package edu.mayo.informatics.lexgrid.convert.directConversions.medDRA.Data.  While this data package defines some of the beans that model the content of lines read from the CSV file, it also organizes them into structures that are easier for the mapping code to user.  Once done the MedDRAMapToLexGrid  can map data objects derived from the MedDRA source into a complete coding scheme object. 

...