Review page for Resolve Broken Data Sources

This page is used to manage the review of the ResolveBrokenDataSourcesSpec.

The value of this approach is that it allows me to track all the issues separately and to drive them to resolution. For me email reviews although nice and informal are almost impossible to track to conclusion. Inline comments to the main document muddy up the document and are also difficult to track to conclusion.

The review process works like this:

  • Add a comment header of the format "Comment <initials>-<number> (<status>)" (see below for examples)
  • A discussion then can take place under that comment header
  • Each comment will have a status at the top, with the status set to Approved, Accepted PDU (pending doc update) or Unresolved
  • If necessary, we do more rounds of discussion until the item is marked as Approved


Commenter Initials Key



This is an example comment

DVC-1 (Resolved)

In the use case where the user is resolving the data source reference, you first give then a dialog to add a new connection. If they want to use an existing connection, they have to press Cancel. That is not intuitively obvious to me. Can't there be a "Use Existing Connection" button? Better yet, can't we combine the two dialogs into one, where I can either pick an existing connection or add a new one, all on one dialog?

- JWB-1 If a connection that corresponds to the missing data source exists then no dialog is opened. The data source will be automatically resolved without popping up any dialogs. Otherwise, the first dialog lists those data sources for which there is no matching connection and/or the project needs to be updated. When selecting the data source from the first dialog and clicking Resolve, the Add Connection dialog will open. If the connection and/or matching driver need to be added then the Add Connection dialog has a capability to add both the driver and connection

- DVC -- Sorry if I missed this, but what if there is an existing connection with a different URL or even a different driver, but it's the connection the user wants to use for the unresolved data source? Is there a way to pick that connection?

- JWB -- I will obtain the database parameters from the project to find the matching connection. If I undestand correctly, if a user wants to use a different connection, and assuming that this discrepant connection refers to a schema with matching tables as the hardcoded reference, then no this is not supported. But this is a good point and probably a separate feature. I'll think about this...

- DVC -- I'm not sure what you mean by "discrepant connection" or "hardcoded reference", but I think we're on the same page. The use case is, I have a database connection already, it doesn't match exactly what the project expects (maybe it's just listening on a different port number, or has a different database name), but I'd like to be able to map it to the data sources in the project. It sounds like there is no way to do this. This seems to me like a pretty common use case, and I am concerned that this will be a non-trivial usability issue.

- JWB -- I would consider this as a separate feature. This feature involves making sure the project works (valid connections registered in the IDE), not to support datasource manipulation. I suggest to file an issue. What might allow support of this would be to persist datasource information in the project as a config file which could be edited (port or server changed)

- DVC -- I think it makes sense to add this as a new issue and track it that way. And I do agree that you can make a project work with what you have. But in some cases it means creating a new connection when you already have a friggin' connection that works just fine for you. It seems like a pretty high annoyance factor.

Also, when you create a new connection, does it have to have the same connection properties as the original connection before it will be accepted? That seems even worse. What if you don't have the default port for a database available on your current machine?

One thing that would help is understanding how much time it would take to build this functionality, and how much time it would take to figure out how much time it would take (the cost of evaluation). Do you have a sense of either of these?

Also, since it's more a question of usability rather than functionality, I'd like to see what the usability reviewers think.

- JWB -- now I'm using the Add Connection dialog from NetBeans and populating the fields based on the data source from the project. Since the fields in the Add Connection dialog are editable, another connection could be applied. If there are any new problems resulting from changing the connection parameters, the user is on their own. The user would have to edit the server specific files, web.xml and possibly the reference to the data source in the Java bean source.

DVC-2 (Resolved)

I know this is a separate issue, but we really need to fix it so that a user doesn't have to manually copy the database driver into the target server, at least for Tomcat, which is the default server that ships with NetBeans.

JWB - This task is tracked by 89439 and 99610 . I have received confirmation that this task is currently being worked on for Glassfish. The driver is copied if the target server is Tomcat, but not for other servers.


JD-1 (Resolved)

I want to follow up on the badging that tells the user that Data Sources need to be resolved. Based on our experience with the PhotoAlbum sample app, it's important that this be obvious to the user.

As I understand it, the proposal here is to badge the Data Source References node, and the broken Data Sources, but not the project itself. Is that right?

That's an improvement from VWP5.5, where only the broken Data Sources were badged. IMO, the ideal case would be to have a badge on the Project itself, as we do for missing server. If I Remember Correctly, you said that there were reasons that the project could not be badged, right?

I have a mild concern that the user won't notice the badged Data Source References node (and may not even expand the project node), so I want to understand the possibilities and tradeoffs here.

JWB - I guess you missed the additional feature to front the Output window and display instructions on how to resolve. The Project node doesn't have to be expanded to front the output window.

Also, badging the project node can be awkward if there happens to be no target server. In this case there should be 2 badges ?

JD - I'm not sure the Output Window is as effective here. This is a little out of keeping with the other information that we put there (compilation errors, etc). I'm not sure the user would pay much attention to the output window when opening a project. Also, since we badge the project for missing servers, this seems to be an analogous case.

Just my $.02. I'm willing to let it go, esp. if badging the project is hard to do. I agree that badging the Data Source References node, and putting a message in the Output Window, is probably Good Enough. It's just that badging the project would be more consistent and more obvious.

JWB- spec send to nb-usability for review

JWB -- nb-usability also preferred the badging to be done on the Project node. Originally this would have been done and it was done for 5.5 Technology Preview release, but the were performance problem using insync modeling. For M9, insync made changes to "improve" the performance by doing the modeling in the background. A startModeling method was added.

JWB -- For M10, badging is done on the Project's node and the Resolve Data Sources action is also on the Project's node.

Not logged in. Log in, Register

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