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

[Hemant S Kolwalkar <hskolwal@xxxxxxxxxx>]

for #3, i meant to say the proposed
model change does not  compel applications (consuming the model) to
create an instance of a Catalog in the model, when connecting to vendor
databases that do not support multiple catalogs (DB2, Oracle, Informix,
Derb, etc). this also applies to migration of persisted resources for these
vendor databases.

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

07/24/2006 12:41 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

Hi Hemant,

> 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.

Question: how are you handling migration of persisted resources given that
the namespace of the base model has changed?


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

While it does introduce the catalog element into the base model, it also
allows the model to be navigated in two different ways.  This will
require
general framework code to be aware of this.  For an example, look
at
DatabaseHelper.findSchema().  How would this be implemented in a generic
way which supports both navigational patterns?  (You might also try
to
explain how this would be implemented for databases which use catalogs
-
table names are unique within a catalog, not a server per the
specification.)


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

Since catalog is part of the base model, they would not need to model it.


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

Seeing as it fails to address the namespacing requirement in a general
manner, I would contend that it is not in keeping with the spirit of the
SQL standard.

Snippet from a previous post:
"Just wanted to reiterate a few requirements.  Feel free to debate
their
relevance.

"The model should allow objects to be namespaced/scoped in a consistent
manner, regardless of whether or not catalogs are supported by a particular
vendor (e.g. catalog.schema.table or schema.table).

"The model should be based upon standard conventions where possible
(e.g.
SQL 99/03, JDBC, etc.)."

Regards,
Rob

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