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

[Hemant S Kolwalkar <hskolwal@xxxxxxxxxx>]

Hi Rob,

i would beg to differ. in my opinion,
neither proposal is inferior and each one has its merits/demerits which
we are discussing on this
forum before making a decision.

regards,

- Hemant

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

07/27/2006 03:45 PM

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

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

Hi Hemant,

Comments in-line below...

> i have also mentioned the goal is to support the modelling of both
> types of vendor databases: those who support multiple catalog
> concept and those who do not. the idea of being compelled to create
> a dummy catalog in the latter case is not very appealing.

The original proposal _is_ capable of supporting all types of vendors'
databases.  As for being compelled to create a dummy catalog, I really
don't think this is a very big deal (vendors have to deal with this when
they write their JDBC drivers).  If a base implementation is provided
by
DTP, it would give existing extenders an easy migration path while
maintaining consistency within the base model.  Providing base
implementations which help extenders is part of building a good framework
(my opinion).

You also need to consider the benefit vendors will get by adhering to a
standard model: the tools built on top of that model; base implementations
for extension points, etc.  I think the benefits to be gained will
outweigh
the cost of dealing with a catalog node (especially if they don't have
to
deal with it because a base implementation is included as part of DTP).


> i understand your concern about model navigation. but as long as we
> document the model change properly. we can also abstract some
> of the navigation wherever possible. for example, the convenience
method
> DatabaseHelper.findSchema()you mentioned.
> agreed, today it ignores catalog namespacing and returns the first
> schema which matches the input string.
>
> with the model change, we have two options.
>
> 1) if we still want to keep this behavior, we can look up to see if
> catalogs are present and if so, enumerate through contained schemas
> of each catalog
>  till a match occurs. else, we can enumerate schemas as we do
today.

This will not work. It ignores the fact that schema names are unique within
catalogs, not within servers (i.e. catalog.schema not schema).


> 2) we can deprecate this method and introduce a similar new method
> which takes Catalog as an additional parameter. in the method, if
> Catalog parameter
> is not null, we enumerate its contained schema till a match occurs.
> else, we can look up to see if catalogs are present and if so,
> enumerate through
> contained schemas of each catalog till a match occurs. if catalogs
> are absent, we can enumerate schemas as we do today
>
> the SQL standard will always serve as our guideline to build the
> model. but from our experience, there are situations where the SQL
> standard can be
> quite vague. in such cases, we have had sometimes to make a call
> based on what is best to provide optimal support to the end consumer.
a
simple
> example is the Index for which we could find no mention in the
> standard. but since the Index is a major element in database systems
> and is supported
> by almost all major vendors, we decided to include it in the model.

Vagaries aside, the specification is quite clear with respect to catalogs
and their use in scoping object names.

In my opinion, this discussion has wandered from focusing on the technical
merits of the two proposals.  I haven't heard any negative comments
on the
technical merits of original proposal (with the exception of migration
concerns, which can be handled as a separate issue and which have not
really been quantified relative to a general migration from RDB to DTP)
and
have only heard justification for why, again my opinion, an inferior
proposal should be accepted.

Regards,
Rob

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