db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3371) Strange (and untested) code fragment in RAMTransaction.addColumnToConglomerate()
Date Fri, 01 Feb 2008 10:05:07 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-3371:

    Attachment: test.diff

The attached patch makes T_AccessFactory.alterTable() run tests on both temporary and non-temporary
conglomerates. This change ensures that the above mentioned code fragment is executed in the

> Strange (and untested) code fragment in RAMTransaction.addColumnToConglomerate()
> --------------------------------------------------------------------------------
>                 Key: DERBY-3371
>                 URL: https://issues.apache.org/jira/browse/DERBY-3371
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: test.diff
> RAMTransaction.addColumnToConglomerate() contains this piece of code:
>             // remove old entry in the Conglomerate directory, and add new one
> 			if (tempCongloms != null)
> 				tempCongloms.remove(new Long(conglomId));
> 			tempCongloms.put(new Long(conglomId), conglom);
> 1. According to the code coverage report (http://people.apache.org/~fuzzylogic/codecoverage/529822/_files/3fc.html#5)
these lines are not tested. If possible, a test that covers them should be added to the regression
> 2. The null check looks either unnecessary (seems to be the case after a brief inspection
of the code), or incomplete since the last line will throw a NullPointerException regardless
of the check if tempCongloms is null.
> 3. The call to remove() before put() is redundant, since HashMap.put() will remove the
old mapping implicitly.
> 4. It seems to me that the object that is put into the HashMap always is the same as
the one that is removed, so perhaps all these lines could be deleted.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message