Bug 134308 - Provide API that allows other modules to register actions on a database node
Provide API that allows other modules to register actions on a database node
Status: NEW
Product: db
Classification: Unclassified
Component: Code
6.x
All All
: P2 (vote)
: TBD
Assigned To: Libor Fischmeistr
issues@db
: API, API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-01 01:27 UTC by David Vancouvering
Modified: 2013-09-04 08:23 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Patch for proposed change (16.75 KB, patch)
2008-06-30 18:50 UTC, David Vancouvering
Details | Diff
Updated patch includes new interface ConnectionActionProvider (20.36 KB, text/plain)
2008-06-30 21:45 UTC, David Vancouvering
Details
Updated patch - missing META-INF changes (20.62 KB, text/plain)
2008-06-30 22:41 UTC, David Vancouvering
Details
Updated patch includes changes recommended by Petr Hejl (29.57 KB, text/plain)
2008-07-01 23:41 UTC, David Vancouvering
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Vancouvering 2008-05-01 01:27:35 UTC
We already have this for the top-level Databases node - we should make this generic for any database node.

This would be done as a friend API in the dbapi module to give it a chance to stabilize.
Comment 1 Andrei Badea 2008-05-01 10:42:17 UTC
Why should we make it generic? Do you know a client for this API in 6.5?
Comment 2 David Vancouvering 2008-05-01 20:00:03 UTC
Yes, there is a client.  The E/R team from Egypt wants to be able to attach the action "Create E/R diagram" to a
connection.  I told them I would try and add this, otherwise their UI is a lot clunkier.
Comment 3 Andrei Badea 2008-05-13 01:11:20 UTC
Ah, I see. Better not to put it in dbapi then. Not a good idea to have external (not in the NetBeans repository)
friends, because then you can't control them.
Comment 4 David Vancouvering 2008-05-13 05:33:22 UTC
Hi, Andrei.  If I don't put it in dbapi, this means creating it as an extension to the (stable) Database Explorer API,
since it's part of the db module.  Are you OK with this? (I am still learning the lay of the land in terms of how APIs
are done).
Comment 5 David Vancouvering 2008-06-30 18:50:42 UTC
Created attachment 63701 [details]
Patch for proposed change
Comment 6 David Vancouvering 2008-06-30 18:54:27 UTC
Please review this addition to the Database API that allows modules to register actions with database connection nodes.

From the architectural spec use case:

----------------

This feature allows modules to provide useful features to users by registering one or more actions with a Database
Explorer connection node.

The module registers an implementation of ConnectionActionProvider in its layer file under the folder
Databases/ConnectionActionProvider. The provider's getActions() method is invoked by the Database Explorer whenever a
connection node needs to know what actions to display. This method is passed in the DatabaseConnection for the current
selected connection, and if you want you can choose which actions, if any, you want to make available for this connection.

Here is an example registration of an ActionProvider:

    <folder name="Databases">
        <folder name="ConnectionActionProvider">
            <file name="MyConnectionActionProvider.instance">
                <attr name="instanceCreate" methodvalue="org.netbeans.testdriver.MyConnectionActionProvider.getDefault"/>
                <attr name="instanceOf" stringvalue="org.netbeans.api.db.explorer.ConnectionActionProvider"/>
            </file>
        </folder>
    </folder>
    

The action can obtain the current DatabaseConnection by implementing CookieAction and specifying DatbaseConnection.class
in the cookieClasses() method. Then in the enable() and performAction() methods of the action, you can call
Node.getCookie(DatabaseConnection.class) to get the DatabaseConnection. You can then use the connection to decide
whether or not the action is enabled and when executing the action. 

-------------------

The patch is attached.  Please don't be confused by the references to RootNodeActionXXX - this is a pre-existing feature
implemented as a friend API.  I renamed it from things like ActionProvider and ActionLoader to RootNodeActionProvider
and RootNodeActionLoader to make a clear distinction between this existing feature and the new support for adding an
action to a Connection node.
Comment 7 David Vancouvering 2008-06-30 21:45:05 UTC
Created attachment 63713 [details]
Updated patch includes new interface ConnectionActionProvider
Comment 8 David Vancouvering 2008-06-30 21:45:46 UTC
Apologies, the patch was missing the new file defining the new interface ConnectionActionProvider
Comment 9 David Vancouvering 2008-06-30 22:41:17 UTC
Created attachment 63716 [details]
Updated patch - missing META-INF changes
Comment 10 David Vancouvering 2008-06-30 22:43:12 UTC
Two things:

- I updated the patch to include a change to META-INF/services for dbapi, to support the name change from DbAction* to
RootNodeAction*

- I noticed this issue was originally to support adding an action to *any* DB Explorer node.  What I implemented is only
for the Connection node.  I think this is a good thing - it keeps things focused, and it's not clear to me why you would
want to add actions to other nodes.  If a specific requirement comes in, we can revisit this.
Comment 11 _ ahimanikya 2008-07-01 03:27:53 UTC
I was hoping that it will not only allow me to customize connection node, it will also allow me to add table and
recreate table, since there may be some extension create command. In my case it will be external table in Axion, may be
in Oracle they also have concept of external table an extension to standard CREATE semantics.

For other nodes, there are lot of possibilities, e.g., one may need bit more than what "Add Column" provides, and may be
 alter table or alter column is also a possibility. If I get the support to add action for "Tables" node, that will be
good enough for me, for now.

In general I observed the DDL capabilities are very limited, specifically no ALTER support, DROP does not have CASCADE,
CREATE does not allow GENERATED column etc. But again these can be done through the sql editor, but people who wanted to
build application/components just leveraging the DBExplorer (like me) will be happy to see it getting richer. 
Comment 12 David Vancouvering 2008-07-01 05:57:54 UTC
Thinking about this further, it's not clear what we would make available on those other nodes, as there are no existing
APIs in the DB Explorer API for things like Column, Table, etc.  If an action is called on a Table node, for example,
what context would we make available?  I'd have to invent a Table class, a Column class, a View class, etc., etc., that
has the information you need.  Starting to sound a bit like a metadata model.

So making it generically available requires more thought, and this late in the game (I have three working days left for
this release) I think it's just not going to happen.

That said, many of the issues you raise are things we should fix in the DB Explorer proper, not as one-off features
provided by another module.  We definitely do want to add things like ALTER COLUMN, ALTER TABLE, cascade support, etc. 
If you need this to, rather than provide it in a separate module, perhaps you can help us make improvements there as
part of our next release? 
Comment 13 _ ahimanikya 2008-07-01 07:51:25 UTC
Agree, we requires more thought on this for sure. Also agree that they will be best suited for DBExplore. 
Comment 14 Petr Hejl 2008-07-01 11:51:31 UTC
PH01: Method getActions() add elements directly to those retrieved from superimplementation. I don't know whether this
is by design or not, but it could be very dangerous. BTW there seem to be possible null pointer dereference at the
beginning of DatabaseNodeInfo.getActions.
PH02: I think some unit test would be very useful for future maintenance.
Comment 15 David Vancouvering 2008-07-01 15:52:01 UTC
Thanks for your review, Petr

PH01: Method getActions() add elements directly to those retrieved from superimplementation. I don't know whether this
is by design or not, but it could be very dangerous. 

Do you mean dangerous because I'm assuming it's OK to add to a list someone else gave me, and I have no control over how
the superimplementation implements the list or what it's doing with it simultaneously?

If so, good point, I'll create a new list.  If you mean something else, please let me know.

BTW there seem to be possible null pointer dereference at the
beginning of DatabaseNodeInfo.getActions.

OK, thanks for catching this.

PH02: I think some unit test would be very useful for future maintenance.

OK.  
Comment 16 Petr Hejl 2008-07-01 16:57:31 UTC
>>Do you mean dangerous because I'm assuming it's OK to add to a list someone else gave me, and I have no control over
how the superimplementation implements the list or what it's doing with it simultaneously?

Exactly.

Comment 17 David Vancouvering 2008-07-01 23:41:31 UTC
Created attachment 63782 [details]
Updated patch includes changes recommended by Petr Hejl
Comment 18 Jaroslav Tulach 2008-07-07 14:33:47 UTC
Y01 Please use getLookup() instead of getCookie
Y02 Do not implement Node.Cookie by any class in your APIs
Y03 Please write a test to show how all the API pieces work together.


Comment 19 _ ahimanikya 2008-07-10 17:09:24 UTC
I am assuming this new API will be public.
Comment 20 David Vancouvering 2008-09-15 16:47:00 UTC
Didn't have time to get to this, will revisit in next release
Comment 21 Jiri Rechtacek 2009-10-16 14:10:08 UTC
Reassigned to new owner.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo