Revision as of 21:27, 17 April 2006

← Back to DTP Main Page

Introduction

This document outlines the steps necessary to specialize DTP frameworks and tools in support of a specific database. The intention is to grow this document (into perhaps a family of linked documents) as community experience grows and contributes to this knowledge base. Questions, suggestions and offers for additional content are appreciated. Please use the DTP Development mailing list or the Discussion section of this page for such conversations.

Suggested Development Environment

If you are going to do serious work extending DTP, then it will pay to have the DTP plug-ins code loaded into an Eclipse development environment, and then to run test by launching platforms from there. This will give to the ability to step through code, capture additional debug output, and generally understand what is happening much quicker than using DTP binary distributions. The current list of DTP plug-ins and instructions for Eclipse CVS access can be found here.

Outline of Steps Required

The amount of work necessary to support a specific database in DTP depends on the level of integration you seek. Starting out at the entry level:

• Try to create a connection to the database using the generic JDBC connection profile. Note the level of correctness and completeness available in the resulting Data Source Explorer (DSE) tree for that database.
• The deviation from the completely correct answer to what has actually happened in step 1 will give you a sense of the work required.

Correcting any deviations in the DSE typically requires model specialization and probably a custom driver definition and connection profile.

Once you have a complete content provider for DSE, the next level of support is within SQL Dev Tools, specifically the SQL editor, the routine (stored procedure) editor, and the results view. SQL Dev uses the models provided by the connection profiles, so you probably will be pleasantly surprised with how much works. No doubt there will be dark corners. To shed light on those, plug-ins extending SQL Dev will be required. Again, the Apache Derby examples in DTP are a good place to start. Finally, unless your database is 100% SQL compliant, and offers nothing beyond the standard (is there any example of this?), then you might want to consider writing a SQL dialect parser for the SQL Parser Framework. This specialized parser will then become a very strong enabling component for specialized editor, and other tooling, support.

Model Specialization

Specializing a model for DTP means taking one or both of the SQL and DBDefinition models and extending them. This is EMF territory: the SQL and DBDefinition models are built using EMF, and hence you will need to use EMF knowledge and techniques to extend them. Fortunately, the Apache Derby examples give a good place to start, and the EMF page linked above has a number of good articles and tutorials.

(More to come in this section...)

Driver Definition and Connection Profiles

SQL Dev Tools

Routine Editor Framework

SQL Results View

SQL Parsers