db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-675) Build-time processing of "metadata.properties" file handles slashes incorrectly.
Date Thu, 03 Nov 2005 00:04:56 GMT
     [ http://issues.apache.org/jira/browse/DERBY-675?page=all ]

A B updated DERBY-675:

    Attachment: d675.patch

Attaching a patch to fix this issue.  The "readLine" method in ODBCMetadataGenerator.java
was treating single backslashes as "end-of-line" markers and hence was not recognizing escaped
sequences like "\n".  It turns out that the check for backslashes in that method is unnecessary,
so this patch removes it.  I ran the metadata.java and odbc_metadata.java tests with this
patch and they ran okay, so I think it should be safe.  I still want to run some more tests
tonight, just to be sure, but I thought I'd post the patch now since it is affecting another
developer's current work (Mamta's).

I will add another comment tomorrow indicating the full test results.

> Build-time processing of "metadata.properties" file handles slashes incorrectly.
> --------------------------------------------------------------------------------
>          Key: DERBY-675
>          URL: http://issues.apache.org/jira/browse/DERBY-675
>      Project: Derby
>         Type: Bug
>   Components: Build tools
>     Versions:,,
>     Reporter: A B
>     Assignee: A B
>     Priority: Minor
>      Fix For:
>  Attachments: d675.patch
> As found and described by Mamta here:
> http://www.nabble.com/-Derby-573-Optimizer-overrides-and-metadata.properties-files-t460642.html
> During the ant build process, Derby's metadata.properties file is modified by the ODBCMetadataGenerator
class and that class treats backslashes that occur in the metadata.properties file incorrectly.
 More specifically, it treats every backslash as the end of a line and thus will translate
things like
> into
> \
> n \
> (in other words, escaped characters like "\n" are handled incorrectly)..

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message