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.
Summary: | Table Layout is damaged after editing RowSet SQL statement in Query Editor | ||
---|---|---|---|
Product: | obsolete | Reporter: | _ alexpetrov <alexpetrov> |
Component: | visualweb | Assignee: | John Baker <jbaker> |
Status: | NEW --- | ||
Severity: | blocker | CC: | blaha, romanmostyka, wjprakash |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
_ alexpetrov
2007-09-06 11:49:16 UTC
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. |