[rules-users] Drools Flow BAM Module(5.1.0.M1) - Why primary key's are of string/varchar type

[Kris Verlaenen]

Does changing the type of the id field from String to long fix your
issue?  Because to me it seems that MySQL is not accepting the name "id"
as a valid column name?  I guess changing the mapping so that it uses a
different column name could fix the issue?

Kris

Quoting Vijay K Pandey <VPandey at mdes.ms.gov>:

> I am using Drools Flow BAM (5.1.0.M1) module to store the processes
> instances for audit purpose. I generated the DDL with the help of
> Hibernate Tools against the MYSQL 5.1(INNODB)
> 
> DDL for the 2 tables are given below -- the interesting part is the
> "id" column as "varchar" ---- this gives error when we try to execute
> the DDL against the mysql.
> 
>    create table AUDIT_NODE_INSTANCE_LOG (
>         id varchar(255) not null auto_increment,
>         type integer,
>         nodeInstanceId varchar(255),
>         nodeId varchar(255),
>         processInstanceId bigint,
>         processId varchar(255),
>         DATE datetime,
>         primary key (id)
>     ) ENGINE=InnoDB;
> 
>     create table AUDIT_PROCESS_INSTANCE_LOG (
>         id varchar(255) not null auto_increment,
>         processInstanceId bigint,
>         processId varchar(255),
>         START_DATE datetime,
>         END_DATE datetime,
>         primary key (id)
>     ) ENGINE=InnoDB;
> 
> The error we get is
> 
> Error: Incorrect column specifier for column 'id'
> SQLState:  42000
> ErrorCode: 1063
> Error occured in:
> create table AUDIT_NODE_INSTANCE_LOG (
>         id varchar(255) not null auto_increment,
>         type integer,
>         nodeInstanceId varchar(255),
>         nodeId varchar(255),
>         processInstanceId bigint,
>         processId varchar(255),
>         DATE datetime,
>         primary key (id)
>     ) ENGINE=InnoDB
> 
> I used a naming strategy for the hibernate that's why the above table
> names.
> 
> My question is when the primary key generation is "native" why not
> let these columns be of  type 'long' and get generated as "bigint"
> for the sql type.
> 
> If they can't be changed - should we just extend the above classes
> and have these fields as long/bigint.
> 
> Any suggestion will be appreciated.
> 
> Thanks
> Vijay
> 




Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm