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

[Hemant S Kolwalkar <hskolwal@xxxxxxxxxx>]

Rob,

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.

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.

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.

regards,

- Hemant

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

07/27/2006 08:34 AM

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

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

I really think it is a bad idea to inject things into the model purely
for
migration purposes, especially given that the effort has not been
quantified and that proposals have been made which would ease this effort.

Hemant's main reason for objecting to the previously agreed upon proposal
is because of migration effort, specifically regarding migration of
persisted model instances.  However, he has failed to quantify this
effort
in relation to the effort required to simply migrate to the existing,
unaltered model in DTP.  When evaluating the proposed changes, he
simply
modified the model within WTP.  I'm curious as to whether or not he
tried
loading these persisted model instances using DTP.

I know I'm probably starting to sound like a broken record, but I really
can't believe that the level of effort required to migrate to the original
proposal is significantly greater than simply migrating to DTP, especially
given that we have come up with a number of approaches that would simplify
this effort (as I've stated previously, it took me less than two hours
each
to migrate the generic JDBC and Derby implementations).

I also think this is a bad precedent to set.  By injecting inconsistencies
into the model (I would classify multiple paths for navigating to objects
an inconsistency), we diminish the usefulness of the base model.  If
we
decide to go ahead with this change, all framework code will need to be
aware of it.  My worry is that this could cause components further
down the
stack to create their own APIs or extension points for accessing or working
with DB objects (because there is no standard, consistent API).

Just my two cents.

Regards,
Rob

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