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.

Bug 114866 - Table Layout is damaged after editing RowSet SQL statement in Query Editor
Summary: Table Layout is damaged after editing RowSet SQL statement in Query Editor
Status: NEW
Alias: None
Product: obsolete
Classification: Unclassified
Component: visualweb (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: John Baker
Depends on:
Reported: 2007-09-06 11:49 UTC by _ alexpetrov
Modified: 2008-02-27 07:49 UTC (History)
3 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description _ alexpetrov 2007-09-06 11:49:16 UTC
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

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.

- JSF Table will contain only 1 column: PERSONID.
Comment 1 _ alexpetrov 2007-09-06 15:41:25 UTC
Priority is downgraded to P2 because user can repair Table Layout.
Comment 2 _ jimdavidson 2007-09-06 18:56:20 UTC
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.
Comment 3 Winston Prakash 2007-09-06 19:03:09 UTC
Assigning to Matt to evaluate this case.
Comment 4 _ jimdavidson 2007-09-06 19:21:03 UTC
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

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.
Comment 5 Matthew Bohm 2007-09-12 02:29:45 UTC
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.