[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[dtp-dev] Suggestion of improvement of catalog loader/sql model extension code for DTP 1.5 M6
|
Hi all!
For DTP 1.5 M6, I have a suggestion
of how to make the catalog loader/sql model extension code easier to use
for adopters. I'm interested in getting feedback from the community at
large before delivering this into the codeline.
I've tested this design in the HSQLDB
case (to customize a level - Schema in that case - to use a pipelined tree
content provider and navigator content extension to remove an IVirtualNode
- Stored Procedures) and I've tested it for Derby, which also works to
customize the table loader for Schema nodes and it works great. It greatly
simplifies things by allowing much more reuse and less re-implementing
the wheel to get things done.
But I'd like to know what you think.
I'll also be posting this on the newsgroup.
Thanks for your time!
--Fitz
Design:
New extension point: org.eclipse.datatools.connectivity.sqm.core.overrideLoader
Each overridden loader element provides
four bits of information: product (vendor), version, overriding class (extends
one of the JDBCBaseLoader classes), eclass (class name to indicate which
model element we are overriding the loader for)
Example:
<extension
point="org.eclipse.datatools.connectivity.sqm.core.overrideLoader">
<loader
provider="org.eclipse.datatools.enablement.hsqldb.catalog.HSQLDBSchemaLoader"
eclass="org.eclipse.datatools.modelbase.sql.schema.Schema"
product="HSQLDB"
version="1.8"/>
</extension>
We would introduce a new manager class
to handle these overridden catalog loaders: CatalogLoaderOverrideManager.
This class provides three methods:
getDbDefinitions()
returns Iterator of the DbDefinitions with registered overriding catalog
loaders
getEClasses(DatabaseDefinition)
returns Iterator of the eclass names with loaders registered for a given
database definition
getLoaderForDatabase
( DatabaseDefinition, eclass name) returns an instance of a class that
extends JDBCBaseLoader that can then be cast to a particular type of catalog
loader such as JDBCSchemaLoader, JDBCCatalogLoader, etc by the given object
Then each wrapper class in org.eclipse.datatools.connectivity.sqm.core.rte.jdbc
(JDBCDatabase, JDBCCatalog, etc.) has code similar to this in its createLoader()
method
protected
JDBCCatalogLoader createLoader() {
DatabaseDefinition
databaseDefinition = RDBCorePlugin.getDefault().getDatabaseDefinitionRegistry().
getDefinition(this.getCatalogDatabase());
JDBCBaseLoader
loader =
CatalogLoaderOverrideManager.getInstance().getLoaderForDatabase(databaseDefinition,
SQLSchemaPackage.
eINSTANCE.getCatalog().getInstanceClassName());
if
(loader != null)
{
JDBCCatalogLoader catLoader = (JDBCCatalogLoader) loader;
catLoader.setCatalogObject(this);
return catLoader;
}
return
new
JDBCCatalogLoader(this);
}
If an overriding catalog loader has been
registered for a particular db definition/eclass pair, it will be returned
here and passed along. If not, we'll stick with the basic method of creating
a default catalog loader.
One change was made to JDBCBaseLoader
in order to facilitate being created as an executable extension from the
plugin extension registry. It had to implement a zero-argument constructor
and add a setCatalogObject(ICatalogObject) method.
But this allows anyone implementing custom
catalog loaders to use the defaults as much as possible and only start
overriding things when they need to.
For example, in the HSQLDB case, we just
want to extend the UI wrappers for the model enough to make the Schema
object unique for HSQLDB databases. This allows us to then intercept and
remove the stored procedure collection node from the UI.
Or in the Derby case, we just want to
override the table loader to include Synonyms.
Brian Fitzpatrick
Senior Software Engineer/DTP Committer
Sybase, Inc.