Announcement Announcement Module
Collapse
No announcement yet.
Mapping type of characters is wrong in reverse engineering Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mapping type of characters is wrong in reverse engineering

    Hi,

    I've reverse engineered a database, and then tried to create the basic web app. When I run the app using "mvn tomcat:run", I get an error and the web app is not loaded. The long stack trace ends with

    Code:
    Caused by: org.hibernate.HibernateException: Wrong column type in PDR.ATTR for column attr_abbr. Found: char, expected: varchar2(16)
    	at org.hibernate.mapping.Table.validateColumns(Table.java:284)
    	at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:1174)
    	at org.hibernate.tool.hbm2ddl.SchemaValidator.validate(SchemaValidator.java:139)
    	at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:389)
    	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1385)
    	at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:954)
    	at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:891)
    	... 55 more
    The datatype in the Oracle database is CHAR(16).

    Code:
    CREATE TABLE ATTR (
    		ATTR_ID NUMBER NOT NULL,
    		ATTR_NAME VARCHAR2(255) NOT NULL,
    		ATTR_ABBR CHAR(16),
    		ATTR_DESC VARCHAR2(4000),
    		STRG_TYPE_ID CHAR(1),
    		REQD_CHK CHAR(1),
    		LOV_CHK CHAR(1),
    		RNGE_CHK CHAR(1),
    		RNGE_MIN_N_VAL NUMBER(5 , 2),
    		RNGE_MAX_N_VAL NUMBER(5 , 2),
    		PREC_N_VAL NUMBER(5 , 2),
    		PRNT_TYPE_ID NUMBER,
    		INDX_ID NUMBER,
    		CNST_ID NUMBER
    	)
    	PCTFREE 0
    	PCTUSED 0
    	LOGGING;
    The generated code by roo is

    Code:
    @Column(name = "ATTR_ABBR", length = 16)
        private String Attr.attrAbbr;

    Below are the roo commands I've run.

    Code:
    project --topLevelPackage org.neoninc.pdr 
    persistence setup --provider HIBERNATE --database ORACLE 
    database properties set --key database.username --value pdr
    database properties set --key database.password --value *******
    database properties set --key database.url --value jdbc:oracle:thin:@dpdb003:1521:dev_pdr
    database reverse engineer --schema PDR --package org.neoninc.db
    controller all --package  ~.web
    perform package
    perform eclipse
    I'm just running the code roo is generating, and I'm not making any other modifications. Do I need to modify the code roo generates to get it to work?

    DJ Spiess

  • #2
    I saw this same issue while working on ROO-1735 for you, but there's nothing I can do here. The column is mapped as a String field which is correct - is that what you expected? The Oracle column is CHAR(16), so it since it is greater than one character, it can't be mapped as a Character or char.

    Even without DBRE, and typing the fields in by hand, unless you allow Hibernate to create the tables and columns for you when you first spin up unit tests or a web app, I don't believe you will have any luck with an existing database like this.

    If you can push-in the fields and refactor them and their JPA annotations so that it works with your existing table, I may then be able to do something. My suggestion is to use EclipseLink, or change the column type to VARCHAR2(16) if you still want to use Hibernate.
    Alan

    Comment


    • #3
      Why would roo generate

      Code:
      @Column(name = "ATTR_ABBR", length = 16)
      private String Attr.attrAbbr;
      instead of

      Code:
      @Column(name = "ATTR_ABBR", length = 16, columnDefinition = “char”)
      private String Attr.attrAbbr;
      Is there a reason this isn't valid? I tried changing it manually, but roo keeps regenerating the file.

      Comment


      • #4
        deege,
        if you want to change the annotation, copy the field definition and annotation into your Attr.java file (probably also include @RooJavaBean on the class)
        Code:
        @Column(name = "ATTR_ABBR", length = 16, columnDefinition = “char”)
        private String attrAbbr;
        roo will 'manage' the Attr_Roo_DbManaged.aj removing the ITD, so whatever you define in the .java will be used.
        [That is what Alan means by 'push-in' the field...]

        Comment


        • #5
          Thanks @Jack. I'll go that route if I can't get the DBA to change the datatypes in the database. Luckily it's possible to alter the schema now, but it won't be when the database gets filled.

          I'm not sure what people are doing for cases where the database is already in use.

          Comment


          • #6
            If the columnDefinition fixes your problem, I can easily add this attribute.

            Comment


            • #7
              Moving the field to the java file and adding the columnDefinition to the attribute "fixed" the exception.

              I put it in quotes because the next offending char column now throws the exception. It will take some time to go through all of the classes to verify, but it does look like adding the columnDefinition to the attribute fixes the exception.

              I think we're going to go the route of changing the columns to varchar, but you might want to investigate it more since I'm sure it will come up again.

              Comment


              • #8
                Mapping type of characters is wrong in reverse engineering

                I'm using the DBRE support intensively on a project with many tables.
                The solution of adding the attribute to the class implies to review all the entities generated.

                It would be very useful to include ColumnDefinition in the annotation Column in the next version of the Addon (in fact I was thinking making the change over the last code but it would be a stopgap measure)

                Comment


                • #9
                  columnDefinition was already added to @Column in ROO-1735 on Dec 7 2010!

                  Comment


                  • #10
                    Problem PK CHAR

                    Hello again,

                    I found that the problem is that the attributes ColumnDefinition and length of the Annotation @Column are not added on Primary Keys of type CHAR..

                    If the attribute is of type CHAR but it is not PK then the annotation is well in the aspect Roo_DbManaged. Is in eht Roo_Entity aspect when the problem happens.

                    Comment


                    • #11
                      As you say, the columnDefinition atttribute is added to fields by DbreMetadata, not EntityMetadata. I will look into this. The attributes of @RooEntity determine how, among other things, the @Id field is created, and currently it does not know about columnDefinition. This may take some time

                      Comment


                      • #12
                        Mapping type of characters is wrong in reverse engineering

                        Thanks a lot!

                        Comment


                        • #13
                          Might be optional the generation of Annotation @GeneratedValue in the addon DBRE

                          Hello again,
                          In this case more than a bug, what I realize is a request:

                          As stated in another post I'm working on a project in which we are doing a reverse engineer a data model rather large:
                          This model uses always functional and non-generated Primary Keys. Currently, once made the reverse engineering we need to extract the @Id from the Aspect to the class and remove the @GeneratedValue.
                          I wonder if in the addon DBRE could be an additional parameter that allows not generate the @GeneratedValue for cases like this.

                          Comment


                          • #14
                            Sorry

                            Sorry, I was wrong to put this post in this thread.
                            I´m going to create a new Thread

                            Comment


                            • #15
                              Originally posted by Alan Stewart View Post
                              columnDefinition was already added to @Column in ROO-1735 on Dec 7 2010!
                              I am still seeing this issue with Roo 1.1.5. I reversed engineered an Oracle database and ran into the same problem. The "push-in" solution "fixed" the issue.

                              Comment

                              Working...
                              X