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.
[ BUILD # : 200808141419 ] [ JDK VERSION : 1.6.0_07 ] Should have a alias name for database connection, which should be used in Services view, SQL History/Command connection combobox etc.
*** Issue 118124 has been marked as a duplicate of this issue. ***
*** Issue 150154 has been marked as a duplicate of this issue. ***
This could be a good candidate for the NetFIX team [1] - hence adding the keyword. If you are willing to implement this take a look into Database Explorer ("db") module. You will have to alter these classes: org.netbeans.modules.db.explorer.dlg.NewConnectionPanel org.netbeans.modules.db.explorer.DatabaseConnection Plus change all DatabaseConnection.getName() method calls to DatabaseConnection.getDisplayName(). [1] http://wiki.netbeans.org/NetFIX
I think that I'd find this useful and so I'll implement this.
Created attachment 86587 [details] patch file
The patch provides the user with a "Display name:" field when creating a new connection. This field is blank by default which will cause the JDBC connection string to display as-per current behaviour. The name appears in the Service window and in the connection drop-down. The display name is persisted so that it is also used after an IDE restart. Finally the display name is also in the properties dialog for the connection and so can be changed. I have tested this against MySQL and SQLServer.
Hi Daniel, thanks for your patch. :-D I tested it against Oracle and JavaDB and works as expected. BTW, I have two points to highlight: MG01: Update license header for all file; MG02: IMHO the connection combo for SQL history should be updated to reflect this change as editor combobox did. Regards and thanks again
Hi Michel, By licence do you mean that I put my name into the list of contributors? I'll get the SQL History working. Should be easy enough to do, but I may not get the patch updated until the weekend as I'm about to be off for a few days. Dan
Thank you for your patch. It works almost without problems :-) Please, see my comments below. JS01: Display Name should be first in properties. JS02: Existing ODBC connection shows empty display name after applying the patch (probably problem in DatabaseConnection.getName()) JS03: NewConnectionPanel: - rename "Name:" to "Driver Name:" - move "Display Name" under "Driver Name" - fix layout of dialog (see screen shots) - displayNameFieldActionPerformed not needed - use label from Bundle - add mnemonic - add accessible name and description - getDisplayName method not used JS04: Check uniqueness of display name. JS05: DBConnection - add javadoc JS06: Keep NetBeans formatting (use Format - Alt+Shift+F on added code) JS07: DatabaseConnectionConvertor - probably wrong condition "if ( ! instance.getUser().equals(instance.getDisplayName()) ) {"
Created attachment 86609 [details] Wrong alignment on Windows JDK1.6 - Field Entry
Created attachment 86610 [details] Wrong alignment on Windows JDK1.6 - URL Entry
Any progress with this?
Thanks for your comments. I believe I now have 2 issues left. The first is that I can't figure out how to play the display field start the start of the tabbing order in the new connection dialog. It is consistently placed last. How is the tabbing order determined? The second issue is that the display name is retrieved via classes/interfaces that are private to the Database Explorer module, but used in the Database Core module. I could avoid any module dependency issues by reading the display name from the XML. Is this the best approach?
Re. field position: I thought you can move it in form designer. But don't worry about it. I will fix it or ask someone if needed. Re. xml: I don't know what the problem is. It should be the same as user name or password.
Created attachment 87184 [details] updated patch
I have added my updated patch. I have been unable to resolve my tabbing issue although I did find that I had a conflict in NewConnectionPanel.form which may not have helped. NetBeans didn't indicate that there was a conflict in the .form file when I was using the GUI builder. Should I file an issue for this? The display name is now used in the SQL history dialog. The complication behind this is that the display name for a connection can be set/changed subsequent to SQL statements being entered into the history - it is the url that defines the connection rather than the name. Such a scenario is when a user decides that they now have a growing number of connections and decides that naming them would help. SQLHistoryPanel works by looking up those connections that have a defined display name and holds them in a pair of maps so that URL (as stored in SQL history) can be mapped to the current display name. My reason for using XMLDataObject via the look-up mechanism to get the display name was that if I stored the display name in the SQL history then all old history statements would not use the display name.
Thank you for your updated patch. I applied it with couple changes. Instead of xml-based connection look-up I used ConnectionManager.getDefault().getConnections(). I enabled Display Name property even if connection is active. After discussion with peers I moved Display name field in connection dialog to the last place because it is optional (same as in your first patch). If someone finds a problem with this new feature, please file a separate issue. core-main #aeff38e79b13
*** Issue 151466 has been marked as a duplicate of this issue. ***
Great news. Thank you Jirko and Daniel!
Integrated into 'main-golden', will be available in build *200909111401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/aeff38e79b13 User: Jiri Skrivanek <jskrivanek@netbeans.org> Log: #144112 - Enable to change display name of connection node.
v. 200909210201
*** Issue 166553 has been marked as a duplicate of this issue. ***
*** Issue 162154 has been marked as a duplicate of this issue. ***
*** Issue 156154 has been marked as a duplicate of this issue. ***