[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [dtp-dev] Suggestion of improvement of catalog loader/sql model extension code for DTP 1.5 M6
|
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