Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0.5
    • Fix Version/s: 1.2.5, 2.0.5, 3.0 beta 1
    • Component/s: None
    • Labels:
      None

      Description

      Hello!
      We are using cayenne and found a bug in class:
      org.apache.cayenne.dba.TypesMapping

      follow lines:

          public static String getJavaBySqlType(int type, int length, int precision) {
              if (type == Types.NUMERIC && precision == 0) {
                  type = Types.INTEGER;
              }
              return (String) sqlEnumJava.get(new Integer(type));
          }
      

      problem occurs when we have NUMERIC(12, 0) which is more then Integer! (Integer has only 10 digets).
      And we wish to conver it to Long not to louse any digets.

      I can sugest to use sumething like this:

          public static String getJavaBySqlType(int type, int length, int precision) {
           if (type == Types.NUMERIC && precision == 0 && length < 10) {
      	    if(length < 10){
                  	type = Types.INTEGER;
      	    } else if (length < 20) {
      		type = Types.LONG;
      	    }
              }
              return (String) sqlEnumJava.get(new Integer(type));
          }
      
      1. CAY-1259.patch
        0.8 kB
        Evgeny Ryabitskiy

        Activity

        Hide
        Andrus Adamchik added a comment -

        The suggested fix idea is likely going in the right direction... Until this is fixed though, I would recommend a workaround to map a given column as BIGINT in Cayenne. It should work in most cases (except for some SQLTemplate uses).

        Show
        Andrus Adamchik added a comment - The suggested fix idea is likely going in the right direction... Until this is fixed though, I would recommend a workaround to map a given column as BIGINT in Cayenne. It should work in most cases (except for some SQLTemplate uses).
        Hide
        Evgeny Ryabitskiy added a comment - - edited

        You mean #result('Column', 'BIGINT") ?

        we are trying to evade from this solution. Our queries can be edited by developers far from Cayenne and usage of not SQL syntax is very undesirable.

        We will fix it in src and compile as a temp solution. Looking forward for this fix.

        thx.

        Show
        Evgeny Ryabitskiy added a comment - - edited You mean #result('Column', 'BIGINT") ? we are trying to evade from this solution. Our queries can be edited by developers far from Cayenne and usage of not SQL syntax is very undesirable. We will fix it in src and compile as a temp solution. Looking forward for this fix. thx.
        Hide
        Evgeny Ryabitskiy added a comment -

        patch with fix for this bug

        Show
        Evgeny Ryabitskiy added a comment - patch with fix for this bug
        Hide
        Andrey Razumovsky added a comment -

        Applied for 3.0 branch. Not sure that it is too critical to apply to 2.0 - corresponding DbAttribute can be mapped in modeler as BIGINT for a workaround

        Show
        Andrey Razumovsky added a comment - Applied for 3.0 branch. Not sure that it is too critical to apply to 2.0 - corresponding DbAttribute can be mapped in modeler as BIGINT for a workaround
        Hide
        Evgeny Ryabitskiy added a comment -

        Thx for reviewing of my patch.

        I can explain why we don't want to use explicit mapping from modeler:

        1) We already have ~10 000+ lines in DomainMap files
        2) We still want not to go far from SQL syntax,

        For me it's obliviously a bug, and it's much easier to fix a bug then to fix all queries...

        Show
        Evgeny Ryabitskiy added a comment - Thx for reviewing of my patch. I can explain why we don't want to use explicit mapping from modeler: 1) We already have ~10 000+ lines in DomainMap files 2) We still want not to go far from SQL syntax, For me it's obliviously a bug, and it's much easier to fix a bug then to fix all queries...
        Hide
        Andrus Adamchik added a comment -

        I don't see a problem for us to apply this to 2.0 and 1.2 branches, as both are officially supported at this point. If Andrey doesn't beat me on it, I can do that in about a week.

        Show
        Andrus Adamchik added a comment - I don't see a problem for us to apply this to 2.0 and 1.2 branches, as both are officially supported at this point. If Andrey doesn't beat me on it, I can do that in about a week.
        Hide
        Andrey Razumovsky added a comment -

        Please do so. i haven't ever worked with 1.2 or 2.0, so setup will take me time

        Show
        Andrey Razumovsky added a comment - Please do so. i haven't ever worked with 1.2 or 2.0, so setup will take me time
        Hide
        Andrus Adamchik added a comment -

        I duplicated the patch on the 1.2 and 2.0 stable branches.

        Show
        Andrus Adamchik added a comment - I duplicated the patch on the 1.2 and 2.0 stable branches.

          People

          • Assignee:
            Andrey Razumovsky
            Reporter:
            Evgeny Ryabitskiy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development