Implements the Farrago metadata catalog.

The Farrago catalog is implemented as an instance of the Netbeans MDR repository. {@link net.sf.farrago.catalog.FarragoRepos} takes care of starting up and shutting down the repository, as well as exposing root packages and providing utilities for querying and updating the catalog.

### Catalog Build

The diagram below provides an overview of the build-time processing which orchestrates catalog definition and access:

There are two inputs to the process:

- The standard CWM data warehouse metamodel. The XMI definition for this metamodel is provided by OMG.
- Farrago-specific extensions, referred to as FEM (the Farrago Extension Metamodel). The UML definition for this metamodel is maintained by the Farrago developers (using the community edition of the Poseidon UML modeling tool from Gentleware.

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:

- org.omg::CWM::ObjectModel::Behavioral
- org.omg::CWM::ObjectModel::Core
- org.omg::CWM::ObjectModel::Instance
- org.omg::CWM::Foundation::DataTypes
- org.omg::CWM::Foundation::KeysIndexes

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`.

### Catalog Population

In addition to preparing an empty catalog, the build also populates it with some initial metadata. Currently, this includes:

- supported datatypes
- builtin data wrappers needed by system
- internal schema defining JDBC metadata views
- sample schemas and data wrappers
- initial configuration information

Eventually, this will include many other things such as the INFORMATION_SCHEMA definition, lists of supported functions, system-owned schemas and procedures, etc. (The sample SALES schema is only for developer testing and will not be present in released distributions.)

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