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.
Product Version: NetBeans IDE 6.0 Beta 1 (Build 200709051200) Java: 1.6.0_02; Java HotSpot(TM) Client VM 1.6.0_02-b06 System: Windows XP version 5.1 running on x86 See also http://www.netbeans.org/issues/show_bug.cgi?id=113693. 1. Connect to DB Derby Travel 2. Create new VWP project (Glassfish V2, Java5 EE, Visual Web JavaServer Faces) 3. DnD JSF Table on Designer. DnD DB table PERSON on it. 4. Use popup menu item "Table Layout" for "table1", move columns "PERSONID, LASTUPDATED" from the list "Selected" to the list "Available". 5. In the window "Navigator" use popup menu item "Edit SQL Statement" for "personRowSet" under SessionBean1. 6. In the Query Editor unmark all checkboxes in the table column "Output" and mark them again. Save All, close Query Editor. Result: - JSF Table will contain only 1 column: PERSONID.
Priority is downgraded to P2 because user can repair Table Layout.
This is an interaction between components/table layout, and changing columns in the data provider. This particular example is a bit of a corner case; will need to determine what the right behavior is.
Assigning to Matt to evaluate this case.
Here's what's going on: When a column is removed from the query, the data provider is updated, and the Table Layout is updated. The column is removed from the Table Layout completely. When a column is *added* to the query, the reverse happens. Data provider is updated, and the Table Layout is updated. The column is added under "Available", but not "Selected", even if it was previously selected. This is exactly the right behavior, IMO. The corner case here is that *all* columns were removed from the query. When the last column is removed, the query becomes invalid, because SQL does not allow an empty select list. The dataprovider is not updated, and the last column is not removed from the Table Layout. This is all fairly consistent behavior. This can be duplicated outside the query editor. Just set the command property of the RowSet to something like "SELECT FROM TRAVEL.PERSON". The workaround is not to remove the last column from the query. Or, the query editor could stop updating the data provider after every user change, and require an explicit save, but that's a bigger issue. The query editor should probably check for this case. I'll look into that. The behavior here is more or less as expected, so I don't think this is a P2.
This is working according to design and, in my opinion, handling quite gracefully the situation where no columns are specified in the SELECT statement. From what I remember, the user's adjusting the query SELECT statement (via the query editor or otherwise) causes CachedRowSetDataProvider.RowSetPropertyChangeListener.propertyChanged to be called which in turn calls CachedRowSetDataProvider.fireProviderChanged which in turn calls TableRowGroupDesignInfo.ProviderListener.providerChanged which (in some cases) modifies the row group's columns. If we want to consider having the query editor require an explicit save, I believe what that means is that we would hold off on calling the rowset's setCommand method until some sort of user gesture (e.g. button click) indicating a save. So I'm changing this to a P3 RFE and reassigning to jimdavidson. Of course, I understand this kind of RFE may be out of scope.