Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dtp-dev] bug#145157 - Derby Synonym issue

Answer from developer:

"isDisplayable is giving any UI some feedback about if it is OK to display your Objects.

For example:

A is a child of B, but you do not want to display as a Tree View like hierarchy A under B.

A is not displayable."

Larry Dunnell
Internet address: ledunnel@xxxxxxxxxx


Hui.Cao@xxxxxxxxxx
Sent by: dtp-dev-bounces@xxxxxxxxxxx

06/06/2006 07:58 PM

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






Thanks Larry,
       Your reply really helps a lot to clarify the containment provider concept. Now I understand how to configure the view by means of the groupid. As you said, the containment provider is a feature of the model and the content provider is the view of the model, but I saw that isDisplayableElement method is defined in ContainmentProvider. What's the purpose of this method, and ContainmentServiceImpl.getContainedDisplayableElements?

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/07/2006 06:54 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








Here is the reply from another engineer:

If they have their own Database type, they could override the getGroupId(EObject obj) method to return their own ID. Doing so will prevent our code from displaying the Schemas Node.

If they want to bypass the display of the ISchemaNode they could then recreate the same Objects that each schema will create: ITableNode... and our contribution would then take back over.

Larry Dunnell
Internet address: ledunnel@xxxxxxxxxx
rcernich@xxxxxxxxxx
Sent by: dtp-dev-bounces@xxxxxxxxxxx

06/06/2006 03:09 PM

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






Hey Larry,

I'm looking into modifying the displayed structure for our ASE database.
In doing so, it does not look like I have the ability to override the
content for my database object.  I get a "Schemas" node or nothing.

I'm looking at AbstractOnDemandContentProviderNav.getChildren().  If the
group ID is GroupID.DATABASE, it adds an ISchemaNode, if it's something
else, it returns an empty array.  (Note, I haven't tested this yet, but
tracing through the code, I don't see any alternatives.)

Thanks in advance for any insight.

Rob

dtp-dev-bounces@xxxxxxxxxxx wrote on 06/06/2006 03:56:32 PM:

>
> This is not a defect and is by design.
>
> For performance reasons, we want to decouple the Logical Containment
> from the DSE display. The DSE content provider  breaks up the
> loading and for most cases only the expanded folder will be loaded.
>
> Since we do not use the logical containment for our DSE content
> provider display for most use-cases, it will not be called from the
> content provider itself.  Also, a containment based view  is not
> always what is most useful to the user.  The existing content
> provider was developed with certain requirements including the
> performance issues mentioned above.  I think if we want to provide
> different views of the model, then DTP should provide an mechanism
> that allows plug-ins to contribute alternate content providers and
> maybe also allows users to toggle between them in the DSE.
>
> In general, the containment provider is a feature of the model and
> the content provider is the view of the model.  It would not be a
> good practice to encourage users to manipulate the containment
> providers for the purpose of altering the display as the containment
> providers are really meant to provide containment information for
> model elements that are not explicitly in a containment relationship
> in the model (Though that wouldn't stop someone from creating a
> content provider that was based on containment.)
>
> Larry Dunnell
> Internet address: ledunnel@xxxxxxxxxx
>
>
>

>
> Hui.Cao@xxxxxxxxxx
> Sent by: dtp-dev-bounces@xxxxxxxxxxx
> 06/06/2006 03:56 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
>
>
>
>
>
> 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

_______________________________________________
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

Back to the top