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.
I create a sample db in derby with two columns. I wanted to remove one of those columns which is not a primary key column. Right clicked on the column node i wanted to delete in the db explorer and the delete action was disabled. i had to manually alter the table and drop that column and even then the db explorer tree didn't refresh its nodes it kept displaying the deleted column as well.
Created attachment 71636 [details] screen shot
It appears that the support to drop columns was not added in 6.5 In 6.1, the version of Derby did not support drop columns. In 10.3.1 or later now DROP COLUMN is supported A workaround is to execute the ALTER TABLE statement in the SQL Editor. http://db.apache.org/derby/docs/dev/ref/rrefsqlj81859.html
If the column still appears, try restarting NetBeans.
While debugging, it looks like the specification for Java DB indicates that remove column is not supported . The "RemoveColumnCommand" property for specification.getProperties() is set to "Supported"=>"false" This seems to contradict my earlier comment : > In 10.3.1 or later now DROP COLUMN is supported > A workaround is to execute the ALTER TABLE statement in the SQL Editor. > http://db.apache.org/derby/docs/dev/ref/rrefsqlj81859.html
For my previous comment, I was investigating DatabaseNodeInfo.getSpecification() which is invoked by ColumnNode.canDestroy()
Hmm,apparently we are bundling 10.2.2, not 10.3.x It looks like we need to upgrade Java DB. It appears that the Java DB driver 10,2.2 doesn't support delete column. The workaround is to "manually alter the table and drop that column"
You're right, John, the spec in our DB support says it's not supported, that's the issue. We need to change it to say it *is* supported. Now, this depends upon the version of Java DB. ALTER TABLE DROP COLUMN was added in version 10.3. So we may need to have dbspec.plist to have two versions of Derby - one for 10.2 and earlier and one for 10.3 and later. Or perhaps we assume ALTER TABLE DROP COLUMN works and let older versions of Derby report an error (seems reasonable to me). You mention that "we bundle 10.2.2". I assume you mean Glassfish? It's up to Glassfish to upgrade their bundled version of Java DB. I suspect GF3 has a newer version of Java DB, as do newer JDK 6 update releases. Also, the user could install their own version of Java DB. So our dbspec.plist needs to be modified to either always support ALTER TABLE DROP COLUMN for Derby or check the version of Derby and enable/disable it depending on the version.
Thanks for the suggestion. The issue is not the driver but Java DB itself. Glassfish v2 ships with 10.2.2 which doesn't support "DROP COLUMN ...." If version 10.3 or later ( I tried 10.4 ) and "DROP COLUMN ..." is supported. I suppose what should be done is if version 10.2 or earlier is used then catch the exception and display an informational dialog to inform the user that Java DB, version 10.3 or later must be used.
For Java DB 10.2.2, if the column is deleted then the error comes from the driver. I don't see a stack trace in NetBeans so I'm not sure how to catch the error. I can enable it for the patch. I noticed Java 6 bundles Java DB 10.4.1 so once I enabled column deletion, deletion will work. I think it's best to enable it.
24ff09bb467b
I'll try setting RemoveColumnCommand's supported property to false if the Derby installation is < 10.3
Integrated into 'main-golden', will be available in build *200810310201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/24ff09bb467b User: John Baker <jbaker@netbeans.org> Log: #149904 enable column deletion for Java DB
I think it's problematic that the column is removed from the explorer and then an exception is reported. I actually think this would be a regression, as currently we don't allow this to happen and the explore model is consistent with the database. It would be much better if we detect the version and then enable/disable based on the version. So I setting RemoveColumnCommand's supported property to false if the Derby installation is < 10.3 is definitely the way to go.
David, this is issue is not marked as fixed. Please see desc13
Thanks, I thought you had closed the issue.
fix available, testing
f3ebb6183e31
The delete action is enabled for all versions of Java DB, but if the version is less than 10.3 then an information dialog is posted to inform the user that column deletion is not supported. If instead the delete action were disabled for versions less than 10.3 then the user would be left out in the dark as to why the action is disabled, I think it's better to inform users.
Integrated into 'main-golden', will be available in build *200811011401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/f3ebb6183e31 User: John Baker <jbaker@netbeans.org> Log: #149904 [65cat] Cannot remove database table column from action
Thanks for the fix, John. - It looks like if for whatever reason the version returned by Derby is not parseable as a double, then we don't handle the NumberFormatException. Perhaps we can catch the exception, log the exception at INFO level, and then assume the version can't handle column deletion. - I think rather than bring up an error dialog for versions that don't support column deletion, we should just disable the action. It looks like, to do this, you'll need to create a new DeleteColumnAction with an enable() method that calls your logic to determine if delete is supported, but I believe this is more user-friendly. Also, that's the way it works today with Derby, so throwing an exception where before we used to just disable the action can be considered a regression. If you disagree, can you please start a dialog on the dev alias with Mike, our HIE guy, asking for his opinion. Thanks! David
> - It looks like if for whatever reason the version returned by Derby is not parseable as a double, then we don't handle > the NumberFormatException. Perhaps we can catch the exception, log the exception at INFO level, and then assume the > version can't handle column deletion. Java DB follows the Java spec versioning. We're not going to have, say a version 12 without the minor version, - this would violate the spec. > - I think rather than bring up an error dialog for versions that don't support column deletion, we should just disable > the action. It looks like, to do this, you'll need to create a new DeleteColumnAction with an enable() method that > calls your logic to determine if delete is supported, but I believe this is more user-friendly. Also, that's the way it > works today with Derby, so throwing an exception where before we used to just disable the action can be considered a regression. I disagree. Part of the reason for this issue being filed is the item is disabled.
Regarding parsing the double, I don't like this approach and can try another way
Yes, but it *should* be disabled if it's an older version, it only became a bug when 10.3 came out. Disabling is much cleaner than making it look like it works and then raising an exception. I'll ask Mike to comment.
logic to be changed
I have one fix that disables the menuitem instead. I'll see if the delete menuitem can be omitted
I think disabling is sufficient, no need to omit it. If you are keen on doing this, the thing to do is look at the getActions() method on DatabaseNodeInfo. You can override it for a ColumnNodeInfo so that it returns the delete action, or not, depending on support of the database. I'm not sure if it's worth it, disabling seems totally fine.
3a14f116136f exclude the Delete action for Java DB < 10.3
Integrated into 'main-golden', will be available in build *200811041401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/3a14f116136f User: John Baker <jbaker@netbeans.org> Log: #149904 exclude Delete action for Java DB < 10.3
Verified with build 081105.
I've transplanted the changesets into release65_fixes repository in following way: http://hg.netbeans.org/main/rev/24ff09bb467b as http://hg.netbeans.org/release65_fixes/rev/da6cb11b3f18 http://hg.netbeans.org/main/rev/f3ebb6183e31 as http://hg.netbeans.org/release65_fixes/rev/c8ffda62e9df http://hg.netbeans.org/main/rev/3a14f116136f as http://hg.netbeans.org/release65_fixes/rev/9ccd125a423b