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

[Brian Payton <bpayton@xxxxxxxxxx>]

I think that Hemant's most recent proposa
is reasonable. (That is, have a link to Schema from both Database and Catalog.)
 DB's that have catalogs will use the Catalog object, and DB's that
don't can omit it and have Schemas attached to Database directly.  The
link from Database to Schema is a reaonable "extension" to the
ISO SQL model. If wouldn't be that difficult for a tool that needs to work
with both types to check whether a particular Database has Schema objects
linked to it.

Regards,
Brian

Brian Payton
SQL Tools Development
IBM Silicon Valley Laboratory
(408) 463-2989, T/L 8-543-2989

Hemant S Kolwalkar/Redmond/IBM@IBMUS
Sent by: dtp-dev-bounces@xxxxxxxxxxx

07/24/2006 02:18 PM

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

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

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