Re: [dtp-dev] Suggestion of improvement of catalog loader/sql model exte

[Der Ping Chou <dpchou@xxxxxxxxxx>]

Brian,

Here are some comment form my team (Loic
Julien):

The approach will only work, but only
for the JDBC catalog loader, I assume this is what we want to achieve

Side observations:

1- In the past, we discussed the idea
to remove folders, the code adding virtual folders should always check
with the Database Definition to see if subject database support the type
to be displayed in DSE. 

However, we do not have all getter
methods to support for supportsyyy() in our Database Definition for
the base SQL Object Type. So by default, some folders cannot be filtered.
-> In addition to your proposal, we should fix that and provide supports
supportsyyy() API for all relevant types of the SQL Base Model.

I had entered https://bugs.eclipse.org/bugs/show_bug.cgi?id=175201
for that.

2- To add folders, no need for a TreePipelinedContentProvider
since there is nothing to remove

Thanks,

Der-Ping

brian.fitzpatrick@xxxxxxxxxx
Sent by: dtp-dev-bounces@xxxxxxxxxxx

03/16/2007 10:43 AM

Please respond to
DTP development mailing list <dtp-dev@xxxxxxxxxxx>

To	dtp-dev@xxxxxxxxxxx
cc
Subject	[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._______________________________________________
dtp-dev mailing list
dtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dtp-dev