kodo.jdbc.meta.MappingFactory: file(SingleFile=true, FileName=mysql.mapping) That way, you can use a clob mapping for Oracle, and a normal value mapping for MySQL (since MySQL doesn't need to use the CLOB mapping, and it isn't very efficient). For more details on this, see: http://docs.solarmetric.com/manual.html#ref_guide_mapping_factory Another solution is to just stick with your custom extension of the MySQLDictionary, which is a perfectly valid way of having special CLOB handling in MySQL. Note, though, that CLOB handling is less efficient than VARCHAR handling, so it should be a mapping of last resort, and there isn't any need to use it in MySQL. In article <cj8h77$6vk$1@solarmetric.netmar.com>, czinczenheim wrote: Hi, I have an application that i'm running with MySQL and Oracle at the same time. At some point, i need to use a 'clob' mapping. When i do this, it just works fine with oracle but it fails with mysql. i have the exception: Field "com.ennov.prisma.api.document.jdo.AbstractDocumentPO.description" is mapped as a clob, but should be represented as a different mapping. If the field is a string and you would like to force it to map as a clob, add an extension to its field metadata with a key of "jdbc-size" and a value of -1.[com.ennov.prisma.api.document.jdo.AbstractDocumentPO.description]

Oracle Community | 3004 | 1 decade ago
tip
Your exception is missing from the Samebug knowledge base.
Here are the best solutions we found on the Internet.
Click on the to mark the helpful solution and get rewards for you help.
  1. 0

    clob mapping not working with mysql

    Oracle Community | 1 decade ago | 3004
    kodo.jdbc.meta.MappingFactory: file(SingleFile=true, FileName=mysql.mapping) That way, you can use a clob mapping for Oracle, and a normal value mapping for MySQL (since MySQL doesn't need to use the CLOB mapping, and it isn't very efficient). For more details on this, see: http://docs.solarmetric.com/manual.html#ref_guide_mapping_factory Another solution is to just stick with your custom extension of the MySQLDictionary, which is a perfectly valid way of having special CLOB handling in MySQL. Note, though, that CLOB handling is less efficient than VARCHAR handling, so it should be a mapping of last resort, and there isn't any need to use it in MySQL. In article <cj8h77$6vk$1@solarmetric.netmar.com>, czinczenheim wrote: Hi, I have an application that i'm running with MySQL and Oracle at the same time. At some point, i need to use a 'clob' mapping. When i do this, it just works fine with oracle but it fails with mysql. i have the exception: Field "com.ennov.prisma.api.document.jdo.AbstractDocumentPO.description" is mapped as a clob, but should be represented as a different mapping. If the field is a string and you would like to force it to map as a clob, add an extension to its field metadata with a key of "jdbc-size" and a value of -1.[com.ennov.prisma.api.document.jdo.AbstractDocumentPO.description]

    Root Cause Analysis

    1. kodo.jdbc.meta.MappingFactory

      file(SingleFile=true, FileName=mysql.mapping) That way, you can use a clob mapping for Oracle, and a normal value mapping for MySQL (since MySQL doesn't need to use the CLOB mapping, and it isn't very efficient). For more details on this, see: http://docs.solarmetric.com/manual.html#ref_guide_mapping_factory Another solution is to just stick with your custom extension of the MySQLDictionary, which is a perfectly valid way of having special CLOB handling in MySQL. Note, though, that CLOB handling is less efficient than VARCHAR handling, so it should be a mapping of last resort, and there isn't any need to use it in MySQL. In article <cj8h77$6vk$1@solarmetric.netmar.com>, czinczenheim wrote: Hi, I have an application that i'm running with MySQL and Oracle at the same time. At some point, i need to use a 'clob' mapping. When i do this, it just works fine with oracle but it fails with mysql. i have the exception: Field "com.ennov.prisma.api.document.jdo.AbstractDocumentPO.description" is mapped as a clob, but should be represented as a different mapping. If the field is a string and you would like to force it to map as a clob, add an extension to its field metadata with a key of "jdbc-size" and a value of -1.[com.ennov.prisma.api.document.jdo.AbstractDocumentPO.description]

      at kodo.jdbc.meta.Mappings.invalidMapping()
    2. kodo.jdbc.meta
      ClobFieldMapping.fromMappingInfo
      1. kodo.jdbc.meta.Mappings.invalidMapping(Mappings.java:132)
      2. kodo.jdbc.meta.Mappings.invalidMapping(Mappings.java:118)
      3. kodo.jdbc.meta.ClobFieldMapping.fromMappingInfo(ClobFieldMapping.java:46)
      3 frames