This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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.
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.
Created attachment 23618 [details] SQL editor provider SPI
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.
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.
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 ;-)
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.
So was this review cancelled? Should it be resolved as WONTFIX?
We agreed on an impl dep (no API), so probably WONTFIX. Closing.