openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aron Lurie <a...@cambridgesemantics.com>
Subject Re: ReverseMapping generated code not compiling (due to non-escaped delimiter)
Date Wed, 19 Feb 2014 16:52:56 GMT
Apologies for the slew of emails, but I just realized that my changes
failed multiple tests
(testTableOps(org.apache.openjpa.jdbc.sql.identifier.TestDBIdentifiers),
testSchemaOps(org.apache.openjpa.jdbc.sql.identifier.TestDBIdentifiers),
testDBIdentifierOps(org.apache.openjpa.jdbc.sql.identifier.TestDBIdentifiers),
testColumnOps(org.apache.openjpa.jdbc.sql.identifier.TestDBIdentifiers)).

I will keep working on a solution.

Aron



On Wed, Feb 19, 2014 at 11:42 AM, Aron Lurie <aron@cambridgesemantics.com>wrote:

> This should make it easier to read the code in my previous email:
>
> http://pastebin.com/0Q19a4XY
>
>
> On Wed, Feb 19, 2014 at 11:33 AM, Aron Lurie <aron@cambridgesemantics.com>wrote:
>
>> Ok - Here is my proposed patch along the lines of option #1 -
>>
>> Index:
>> openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/identifier/DefaultIdentifierConfiguration.java
>> ===================================================================
>> ---
>> openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/identifier/DefaultIdentifierConfiguration.java
>>   (revision 1569020)
>> +++
>> openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/identifier/DefaultIdentifierConfiguration.java
>>   (working copy)
>> @@ -52,7 +52,7 @@
>>      }
>>
>>      public String getLeadingDelimiter() {
>> -        return IdentifierUtil.DOUBLE_QUOTE;
>> +        return IdentifierUtil.ESCAPED_DOUBLE_QUOTE;
>>      }
>>
>>      public String getIdentifierDelimiter() {
>> @@ -73,7 +73,7 @@
>>      }
>>
>>      public String getTrailingDelimiter() {
>> -        return IdentifierUtil.DOUBLE_QUOTE;
>> +        return IdentifierUtil.ESCAPED_DOUBLE_QUOTE;
>>      }
>>
>>      public boolean getSupportsDelimitedIdentifiers() {
>> Index:
>> openjpa-lib/src/main/java/org/apache/openjpa/lib/identifier/IdentifierUtil.java
>> ===================================================================
>> ---
>> openjpa-lib/src/main/java/org/apache/openjpa/lib/identifier/IdentifierUtil.java
>>     (revision 1569020)
>> +++
>> openjpa-lib/src/main/java/org/apache/openjpa/lib/identifier/IdentifierUtil.java
>>     (working copy)
>> @@ -24,6 +24,7 @@
>>   */
>>  public interface IdentifierUtil {
>>      public static final String DOUBLE_QUOTE = "\"";
>> +    public static final String ESCAPED_DOUBLE_QUOTE = "\\\"";
>>      public static final String DOT = ".";
>>      public static final String UNDERSCORE = "_";
>>      public static final String SPACE = " ";
>>
>>
>>
>>
>>
>> On Mon, Feb 17, 2014 at 5:48 PM, Rick Curtis <curtisr7@gmail.com> wrote:
>>
>>> I would start with option #1
>>>
>>> Thanks,
>>> Rick
>>>
>>>
>>> On Mon, Feb 17, 2014 at 11:31 AM, Aron Lurie <
>>> aron@cambridgesemantics.com>wrote:
>>>
>>> > Hi All,
>>> >
>>> > Running on trunk, I'm currently facing a problem very similar to
>>> > OPENJPA-1540. When I run the ReverseMappingTool on an Oracle database
>>> with
>>> > a lowercase column name, I end up with syntactically incorrect source
>>> code.
>>> > Whereas I should get output like this:
>>> >
>>> > @Column(name="\"foobar\"")
>>> >
>>> > I instead get un-compileable output like this:
>>> >
>>> > @Column(name=""foobar"")
>>> >
>>> > The reason why the problem only affects lowercase column names is
>>> because
>>> > Oracle generally requires names in all upper case. If a name is
>>> specified
>>> > with quotes around it, then it can be allowed to contain lowercase
>>> > characters.
>>> >
>>> > I generally see two ways I can fix this:
>>> >
>>> > 1) Change the way the DBIdentifier's are initialized to surround the
>>> > identifier with a delimiter that includes the escape \.
>>> >
>>> > 2) Change the serialization stack (i.e.
>>> > AnnotationPersistenceMetaDataSerializer.serialize and
>>> > AnnotationEntry.toString) to run some character escape utility (like
>>> > StringEscapeUtils.escapeJava) at String construction time.
>>> >
>>> > Which approach here is best? Or is there a better way I haven't
>>> considered?
>>> >
>>> > Thanks,
>>> > Aron
>>> >
>>>
>>>
>>>
>>> --
>>> *Rick Curtis*
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message