Re: [dtp-dev] Fw: about the DTP model change proposal for Catalog - plea

[Hemant S Kolwalkar <hskolwal@xxxxxxxxxx>]

providing a "migration kit"
is a good idea if the model change is disruptive. but we do have solutions
which are non-disruptive.

the model change that i have proposed
(see below) :

1. eliminates the need for migration,
both at code and persisted resource level, for existing consumers of WTP
as well as DTP by maintaining model compatibility.

2. introduces a Catalog element to address
the need of vendors who support multiple catalogs (Sybase, SQLServer).

3. does not  compel vendors who
do not support multiple catalogs (DB2, Oracle, Informix, Derb, etc) to
model the Catalog. 

4. is in keeping with the spirit of
the SQL standard.

thanks,

- Hemant

rcernich@xxxxxxxxxx
Sent by: dtp-dev-bounces@xxxxxxxxxxx

07/19/2006 01:03 PM

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

To	DTP development mailing list <dtp-dev@xxxxxxxxxxx>
cc
Subject	Re: [dtp-dev] Fw: about the DTP model change proposal        for        Catalog        -        please read

> Thank you for raising these as points to be considered
for DTP.
> Another area too, which need to be factored in related to WTP to DTP
> migration. There will be a variant proposal which is focusing on
> current WTP adoption migrating to DTP, for an easy path of the
> migration as well as supporting the catalog object.

I agree that this is an important aspect.  However, I don't think
the base
model should be affected by migration requirements unless absolutely
necessary.  My preference would be to provide a "migration kit"
that could
be used by existing adopters.  This "kit" would be part
of the DTP model
base project and would provide a customized model that can be used by
extenders that do not support catalogs (e.g. including NonCatalogDatabase
and NonCatalogSchema elements).

As for persisted models, I think we should consider using migration
mechanisms provided directly within EMF (e.g. element name mapping;
Database->NonCatalogDatabase).  We could also include a specialized
ExtendedMetaData implementation as part of this "kit."  This
could serve as
a base type for more sophisticated, customized models.  (As an aside,
I'm
curious as to why you wouldn't need to create one of these anyway, since
the namespace URI's of the base types have changed; or, at a minimum, use
an XML name to feature map.)

Rob

_______________________________________________
dtp-dev mailing list
dtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dtp-dev