The first step of the catalog build is to combine the two models into a single XMI file before further processing. This requires a bit of XMI massaging; custom XSL scripts make this reasonably painless. (Since MDR uses MOF, we use the UML2MOF tool to convert FEM.) Some filtering is also performed; for example, Farrago only uses the following CWM packages:
Next, the combined metamodel is imported into a new MDR repository instance and stored in an extent named FarragoMetamodel. A singleton instance of this metamodel is instantiated with extent name FarragoCatalog; this will store actual catalog data.
Besides storage, model-specific Java interfaces are also required for accessing the catalog at runtime. For example, a table is represented by {@link net.sf.farrago.cwm.relational.CwmTable}. The build calls MDR to generate these from the metamodel. The CWM interfaces are generated under package {@link net.sf.farrago.cwm}, and the FEM interfaces are generated under package {@link net.sf.farrago.fem}. Custom code-generators in {@link net.sf.farrago.catalog.codegen } take care of generating convenience class {@link net.sf.farrago.FarragoMetadataFactory } and C++ code used for JNI access to the model (TODO: link).
As shown at the bottom of the diagram, a DTD is also generated which describes the XMI format of catalog import/export data (all of which is implemented by MDR).
For more details on the build process, please study the createCatalog
target in //open/dev/farrago/build.xml
.
Once the system is fully initialized, DDL statements executed by users can also modify the catalog. The geneneric DDL implementation is in {@link net.sf.farrago.ddl}. Specific validation and storage rules for various catalog objects are supplied by {@link net.sf.farrago.ddl.DdlHandler}.
Revision | $Id: //open/dev/farrago/src/net/sf/farrago/catalog/package.html#9 $ |
---|---|
Copyright | Copyright (C) 2005-2009 The Eigenbase Project
Copyright (C) 2005-2009 SQLstream, Inc. Copyright (C) 2005-2009 LucidEra, Inc. |
Author | John V. Sichi |