| Suggestion of improvement of catalog loader/sql model extension code for DTP 1.5 M6 [message #27932] |
Fri, 16 March 2007 17:45 |
Eclipse User |
|
|
|
Originally posted by: brianf.sybase.com
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 to the
dtp-dev mailing list.
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.HSQLDBSchema Loader "
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().getLoaderForDatab ase(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.
|
|
|
Powered by
FUDForum. Page generated in 0.02273 seconds
] 
Search
Help
Register
Login
Home
