Bug 61948 - API for opening an SQL editor
API for opening an SQL editor
Status: RESOLVED WONTFIX
Product: db
Classification: Unclassified
Component: Code
5.x
All All
: P2 (vote)
: 5.x
Assigned To: apireviews
issues@db
: API, API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-08 16:42 UTC by Andrei Badea
Modified: 2005-10-18 10:45 UTC (History)
5 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
SQL editor provider SPI (1.28 KB, text/plain)
2005-08-09 19:39 UTC, Andrei Badea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrei Badea 2005-08-08 16:42:24 UTC
In the Database Explorer (db module) there are two actions which open the SQL
editor:

- Execute Command - opens a new, empty SQL editor 
- View Data - opens a new editor containing a "SELECT * from table" statement
and executes it

The SQL editor (in the db/sqleditor module) has a combo box in the toolbar which
allows the user to select the connection which the statements in the editor are
executed against. The editors opened by invoking the two actions mentioned above
must have this combo box set correctly (to the connection on which these actions
are invoked).

A way to solve this problem would be to add an SPI for opening an SQL editor:

interface SQLEditorProvider {
    public DataObject openSQLEditor(DatabaseConnection dbconn, String sql);
}

which could be implemented by the sqleditor module. There could be more usages
in the future (for example opening a SQL editor for a SQL statement in a Java
file), but they are not thoroughly investigated at the moment.

Therefore the question is where to put this interface and whether it should be
in a public or friend API.

If the API is friend, a new module (for example ddapi) must be created (since
the interface can not reside in the db module, which already provides the public
Database Explorer API described in issue #61439). But it would be a module of a
single class, maybe two (if a support class is created which would delegate to
the SPI). The db and sqleditor modules will then have a friend dep on ddapi.

The alternative would be the db module. This which would put this interface in
the public packages. But since the db module will provide a stable API and since
the use cases are not clear, I feel a little unsure about putting in there now.
After all, it can be added at any time. Anyway, I would welcome any opinion.
Comment 1 Andrei Badea 2005-08-09 19:38:18 UTC
It seems that the simplest way to solve this is by adding an implementation
dependency between the module db and sqleditor. The impl dep can be removed when
the SQL editor provider SPI is more clear and is moved to public API. The impl
dep is inside the ide cluster, so this is hopefully not a problem.

I'm attaching the interface that makes up this SPI. It belongs to the db module
and the sqleditor module implements it and puts the implementation in the
default lookup.
Comment 2 Andrei Badea 2005-08-09 19:39:39 UTC
Created attachment 23618 [details]
SQL editor provider SPI
Comment 3 Pavel Buzek 2005-08-09 20:07:47 UTC
As I already told Andrei offline my preference is to add this as a regular SPI
into db module (i.e. with stability level "under development") and maybe
document that it is not recommended for use as an API, only as an SPI.

I am against creating implementation dependency.

I would like to see other opinions.
Comment 4 Pavel Buzek 2005-08-10 18:18:44 UTC
Andrej convined me that the impl. dep will be best in these conditions.
As decribed in 54123 Jesse G. used the same solution for projects.
Too bad we cannot have friend and public api in one module.
Comment 5 Jaroslav Tulach 2005-08-10 18:24:09 UTC
I found the impl. dep better then  
1. creation of new module with just one api class in it 
2. creating false expectations about this API in the db explorer 
 
As these modules are close to each other and developed by Andrei, I hope 
things should go without problems. Those modules will always be build 
together, spec. versions increased together, especially when spec.codebase (or 
how the project.properties property is called) is used. 
 
However if you go the spi way, then please document the class better. I had 
hard troubles to find out how to use it. 
 
Btw. If you decide to put this class into SPI, and you do not want other 
people to implement it, you can restrict the impl class in constructor assert 
(getClass().getName().equals("the-class-you-want")) and make all the methods 
protected. Then you effectively prevent anyone to call the method and nobody 
can subclass, so the class is really "friend" api ;-) 
Comment 6 _ rkubacki 2005-08-10 18:34:53 UTC
There is just one use case now so let's keep it simple and impl dep seems to be
simplest now as we cannot have friend and public API in one module and we are
not sure if the solution is final.
Comment 7 Petr Jiricka 2005-10-18 08:48:04 UTC
So was this review cancelled? Should it be resolved as WONTFIX?
Comment 8 Andrei Badea 2005-10-18 10:45:20 UTC
We agreed on an impl dep (no API), so probably WONTFIX. Closing.


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