[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dtp-dev] bug#145157 - Derby Synonym issue
|
Additionally, I've noticed that the base SQL model does not align very well
with the default containers. For example, there is a views container, but
no views container on the Schema object (furthermore, views are added to
the tables container by the two supplied catalog loaders, Derby and generic
JDBC); SP's and UDF's are individually distinguished within the model, but
are exposed through the routines container by the Derby catalog loader; no
SP's or UDF's are loaded by the generic JDBC catalog loader.
Also, I think the generic JDBC catalog loader should be enhanced to fully
populate the model (e.g. SP's, UDF's, UDT's, super/sub tables, etc.). It
currently only populates views and tables.
Rob
dtp-dev-bounces@xxxxxxxxxxx wrote on 06/06/2006 06:55:35 AM:
> Adding to Hui's thoughts, I think this will have some bearing on
> issue covered the mail I sent earlier, reg. the SynonymFolder
> created within Derby context showing in non-Derby Schemas too.
>
> Regards
> Anthos
> On 06/06/2006, at 8:56 PM, Hui.Cao@xxxxxxxxxx wrote:
>
>
> Hi Larry,
> I also debugged into the XXXContainmentProvider classes as
> Anil did and found that the getContainedElements method in
> ContainmentProviders is not called by the framework at all. But at
> first I thought this should be the most important API in
> ContainmentProvider. So I created a defect 145506 for this problem
> and the following is the defect description:
>
> We have a requirement to show the schema objects for a
> specific database in DSE in a different way with the default behavior.
> At first, I considered using "logicalContainment" extension point
> defined in org.eclipse.datatools.connectivity.sqm.core. Enablement
> plugins are required to provide extensions to it and I thought it
> would give us the capability to arrange sql model objects freely.
> But Actually the logical relationship in DSE is determined by
> ServerExplorerVNodeContentProviderNav class. E.g. to display
> children of a schema object, we have the following code in
> ServerExplorerVNodeContentProviderNav:
> protected Object[] displaySchemaChildren (Object parent)
> {
> DatabaseDefinition df = getDatabaseDefinition (parent);
>
> List collection = new ArrayList (7);
> collection.add(nodeFactory.makeTableNode(TABLE,
> TABLE, parent));
> collection.add(nodeFactory.makeViewNode(VIEW, VIEW,
parent));
> collection.add(nodeFactory.
> makeStoredProcedureNode(STORED_PROCEDURE, STORED_PROCEDURE, parent));
> collection.add(nodeFactory.makeUDFNode(UDF, UDF,
parent));
> ...
>
> While at the same time, in XXXContainmentProvider, the
> getContainedElements method are never called by the framework. E.g.
> in SchemaContainmentProvider:
> public Collection getContainedElements(EObject obj) {
> Collection children = super.getContainedElements(obj);
> Schema schema = (Schema) obj;
> children.addAll(schema.getTables());
> children.addAll(schema.getRoutines());
> children.addAll(schema.getSequences());
> children.addAll(schema.getUserDefinedTypes());
> children.addAll(schema.getAssertions());
> children.addAll(schema.getCharSets());
> return children;
> }
>
> My thought is: since the logicalContainment extension point is
> already there, why can't we enhance it and move the containment code
> from ServerExplorerVNodeContentProviderNav to
> XXXContainmentProvider? So that enablement plugins will have more
> flexibility to control the logical relationships between the sql
> model objects in DSE. Of course, we also have to handle
> contributions from multiple vendors properly. The following code
> snippet just show one of the possibilites:
> <containment
>
package="http:///org/eclipse/datatools/modelbase/sql/schema.ecore";
> class="Schema"
> provider="org.eclipse.datatools.connectivity.sqm.
> internal.core.containment.SchemaContainmentProvider">
> <includes>
> <databaseDefinition vendor="DB2" version="8.2"/>
> </includes>
>
> </containment>
>
> Any thoughts? Correct me if I'm wrong. Thanks!
>
>
> Best Regards!
>
> Max ( Hui ) Cao
> DTP SQL Dev Tools Committer
> Sr S/W Eng - Dev
> Sybase, Inc. Shanghai, China
>
>
>
> Lawrence E Dunnell <ledunnel@xxxxxxxxxx>
> Sent by: dtp-dev-bounces@xxxxxxxxxxx
> 06/06/2006 02:03 AM
>
> Please respond to
> DTP development mailing list <dtp-dev@xxxxxxxxxxx>
>
> To
>
> DTP development mailing list <dtp-dev@xxxxxxxxxxx>
>
> cc
>
> Subject
>
> Re: [dtp-dev] bug#145157 - Derby Synonym issue
>
>
>
>
>
> If all of the DTP projects are pulled into a workspace, then Eclipse
> can check for references to AbstractContainmentProvider in DTP. I
> did this and found that several of the classes (I did not check them
> all) extending AbstractContainmentProvider override all the methods, so
> AbstractContainmentProvider would never get called.
>
> Larry Dunnell
> Internet address: ledunnel@xxxxxxxxxx
>
>
>
> Anil T Samuel <anil.samuel@xxxxxxxxxx>
> Sent by: dtp-dev-bounces@xxxxxxxxxxx
> 06/04/2006 05:58 PM
>
> Please respond to
> DTP development mailing list <dtp-dev@xxxxxxxxxxx>
>
> To
>
> DTP development mailing list <dtp-dev@xxxxxxxxxxx>
>
> cc
>
> Subject
>
> [dtp-dev] bug#145157 - Derby Synonym issue
>
>
>
>
>
>
>
> Hi
>
> When I tried a Debug with breakpoints in all methods of
> AbstractContainmentProvider and DerbySynonymContainmentProvider, the
> execution didnot stop in any of these. I can understand in case
> DerbySynonymContainmentProvider since the folder/group itself is not
> appearing in DSE; but what about AbstractContainmentProvider ?
>
> Regards
> Anthos
> Lawrence E Dunnell wrote:
> >
> > By the way, my change for
> > 145157 will not fix the problem. However,
> >
> > I was able to repro this in the debugger and it will require a code
> > change.
> > Still investigating the solution.
> >
> > Larry Dunnell
> > Internet address: ledunnel@xxxxxxxxxx
> >
> >
> >
> >
> > *jograham@xxxxxxxxxx*
> > Sent by: dtp-pmc-bounces@xxxxxxxxxxx
> >
> > 06/02/2006 05:14 PM
> > Please respond to
> > DTP PMC mailing list <dtp-pmc@xxxxxxxxxxx>
> >
> >
> >
> > To
> > DTP development mailing list <dtp-dev@xxxxxxxxxxx>
> > cc
> > dtp-pmc@xxxxxxxxxxx
> > Subject
> > [dtp-pmc] Re: [dtp-dev] DTP 0.9 RC5 6/2 2nd build
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Larry,
> >
> > Thanks very much for the quick turn around on these issues!
> >
> > For 145156, I think the best solution for Callisto is to deliver this
> > plug-in unjarred, and then work on the necessary changes later. If the
PMC
> > agrees, this will just be a simple change to the build process for this
> > plug-in.
> >
> > Regards,
> > John Graham
> > Eclipse Data Tools Platform PMC Chair
> > Staff Software Engineer, Sybase, Inc.
> > http://dataplat.blogspot.com/
> >
> >
> >
>
>
> > Lawrence
E
> >
Dunnell
> >
<ledunnel@xxxxxx. To
> > com> DTP development mailing
list
> > Sent
by: <dtp-dev@xxxxxxxxxxx>
> >
dtp-dev-bounces@e cc
> >
clipse.org dtp-pmc@xxxxxxxxxxx
> >
Subject
> > Re: [dtp-dev] DTP 0.9 RC5 6/2
2nd
> > 06/02/2006
07:49 build
> >
PM
>
>
>
>
> > Please respond
to
> > DTP
development
> > mailing
list
> >
<dtp-dev@eclipse.
> >
org>
>
>
>
>
> >
> >
> >
> >
> >
> > The fix 145156 turns out to not be trivial and world require a change
to
> > the labeService extension point implementation and to all consumers of
the
> > extension point. The PMC will have to decide whether or not to make
> > such a
> > change this late in the game. The workaround is to not single-jar the
> > plug-in.
> >
> > I am unable to repro 145156 in my workspace under the debugger. I did
> > notice some issues in the plugin.xml for the
> > org.eclipse.datatools.connectivity.derby plug-in and committed the
> > changes.
> > We'll have to test another build to see if that fixed the problem.
> >
> > Larry Dunnell
> > Internet address: ledunnel@xxxxxxxxxx
> >
> >
> >
>
>
> > Lawrence
E
> >
Dunnell/Redmond/IBM@IBMUS
> > Sent by:
To
> > dtp-dev-bounces@xxxxxxxxxxx DTP development
mailing
> > list
<dtp-dev@xxxxxxxxxxx>
>
> cc
> > 06/02/2006 03:48
PM
> >
Subject
> > Re: [dtp-dev] DTP 0.9
RC5
> > Please respond to 6/2 2nd
build
> > DTP development mailing
list
>
> <dtp-dev@xxxxxxxxxxx>
>
>
>
>
>
>
>
>
>
>
> >
> >
> >
> >
> >
> >
> > I am testing a fix for these two problems. Will deliver soon. It
> > looks to
> > be a trivial change to plugin.xml.
> >
> > Larry Dunnell
> > Internet address: ledunnel@xxxxxxxxxx
> >
> >
>
>
> >
jograham@xxxxxxxxxx
> > Sent by:
dtp-dev-bounces@xxxxxxxxxxx
>
>
>
> To
> > 06/02/2006 02:44 PM
dtp-dev@xxxxxxxxxxx
>
> cc
>
>
> > Please respond to
Subject
> > DTP development mailing list [dtp-dev] DTP
0.9
> > <dtp-dev@xxxxxxxxxxx> RC5 6/2 2nd
build
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> >
> >
> >
> >
> >
> >
> >
> > A second build of DTP 0.9 RC5 6/2 is now available on the DTP download
> > site. This contains a fix for the problem of synonyms not appearing in
the
> > Data Source Explorer tree:
> >
> > http://dev.eclipse.org/mhonarc/lists/dtp-dev/msg00543.html
> >
> > Note that we have observed the following bugs in this area, neither of
> > which functionally impact this new build:
> >
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=145156
> >
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=145157
> >
> > Regards,
> > John Graham
> > Eclipse Data Tools Platform PMC Chair
> > Staff Software Engineer, Sybase, Inc.
> > http://dataplat.blogspot.com/
> >
> > _______________________________________________
> > 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
> > _______________________________________________
> > dtp-dev mailing list
> > dtp-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dtp-dev
> >
> >
> > _______________________________________________
> > dtp-pmc mailing list
> > dtp-pmc@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dtp-pmc
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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
> _______________________________________________
> 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
>
> _______________________________________________
> dtp-dev mailing list
> dtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dtp-dev
