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.
Short Issue Description: Expose friend API in db/visualsqleditor module, so that the visualweb/dataconnectivity can continue to use the Visual SQL Editor to modify SQL command properties of RowSets. Longer Description: The Visual SQL Editor was developed as a feature of Java Studio Creator, where it was used to edit the SQL command property of RowSets. When Creator was reorganized as the Netbeans Visual Web Pack, the Visual SQL Editor became a module of the Visual Web Pack. The module has now been moved over to the db cluster, as a step towards making it accessible to other Netbeans modules. The first step is to revise and expose the current API, so that current client in visualweb/dataconnectivity can continue to use the editor. We are asking to make this a friend API. Target milestone: M8 Dependencies on other issues and issues that depend on this one: Issue #90447 (Export VWP SQL Query editor to NetBeans) depends on this issue. As far as I can tell, this issue does not depend on any other issues. An explanation of the change in architecture or API: The architecture of the Visual SQL Editor does not change. See the current functional specification for more information about the editor: http://wiki.netbeans.org/wiki/view/VisualSQLEditorFunctionalSpecification Besides being exposed as a friend API, the API is also being simplified. The original version was developed when there was tighter coupling between the editor and its client. A list of the interfaces impacted by the change that the module offers (imports) and depends on (exports): The db/visualsqleditor exports a single API, which is the one proposed here. It depends on some features of the DB Explorer, such as DatabaseConnection. It does not depend on any features of the visualwebsuite. The specification (e.g. javadoc) and stability category (aka commitment level) for each interface: Javadoc for the proposed interface is attached. Stability level: friend
Created attachment 39449 [details] Initial JavaDoc for proposed API
[RK01] I do not see what is VisualSQLEditorMetaData good for. API users cannot create or obtain instance of this class so you can't call its methods and they will always pass null to VisualSQLEditorFactory.createVisualSQLEditor.
Let me see if I can clarify: First, note that VisualSQLEditorMetaData is an interface. API users will create a class that implements the interface. They will not *use* the methods of VSEMD; rather, they will *implement* them. The VisualSQLEditor will use the metadata instance. This is intended to allow performance optimizations with respect to metadata retrieval, which can be slow. For example, the caller may elect to retrieve all the metadata in advance, and share it across several instances of the VisualSQLEditor. If you have further questions, please let us know.
If you expect that other modules will implement VisualSQLEditorMetaData then it belongs to SPI rather than to API. As a result it means that you need to plug your implementation through this SPI in order to be able to use the API effectively. Is this tight coupling what you expect?
Yes, that's how the API should be used. The VisualSQLEditorMetaData interface is a workaround for the lack of a database metadata model in NetBeans. I started implementing such a model in issue 61441, but never got the permission to finish it. With the model there would not have been a VSEMD interface at all. But it must be there, and it is the very reason why this API is not public. The visual web component (which is the only client of the visual SQL editor API) caches database metadata anyway, so it makes sense for it to pass the metadata on to the visual editor. Otherwise the editor would have to retrieve the metadata itself on each invocation, leading to worse performance. As to whether this is SPI or API: in this case the service provider is the same as the client, so I don't see any point in separating VSEMD into a separate SPI.
This has been on apireviews for more than a month now, so it can probably be closed.
Closing.