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

[rcernich@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.

After reviewing the Informix documentation, it appears that Informix could
make use of the catalog element too.  It supports accessing objects across
databases (catalogs) using the syntax db:dbo.object.  The active database
can be set programmatically using SQL (the documentation states that
Connection.setCatalog() is not supported).

Also, could you please respond to my other questions.

Thanks in advance,
Rob

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