To set length of Datanucleus db2 column of type CLOB to 1M


mayank.chawla@...
 

Hello,

I am migrating from Datanucleus version 2.0.4 to 5.x. In 2.0.4 version, length for DB2, CLOB columns used to come as "1M" when schema gets created. Now, in 5.2.3, length for DB2, CLOB columns is coming as 2147483647(ex: USER_X CLOB(2147483647),DESC_X CLOB(2147483647)) in create queries, but need to have column length for CLOB columns as 1M. 

In Datanucleus RDBMS 2.0.4 jar, I noticed there is a method getUnlimitedLengthPrecisionValue in DB2Adapter class, which I believe result in length of 1M. Please find the method definition below,
public int getUnlimitedLengthPrecisionValue(SQLTypeInfo typeInfo)
    {
        if (typeInfo.getDataType() == java.sql.Types.BLOB || typeInfo.getDataType() == java.sql.Types.CLOB)
        {
            return 1 << 30;
        }
        else
        {
            return super.getUnlimitedLengthPrecisionValue(typeInfo);
        }
    }

I checked similar method in Datanucleus RDBMS 5.2.3 jar but its not present. Kindly advice how this can be achieved - by adding some configuration or through above method. I might have missed on any important detail which might be required to answer this question, please let me know if any information is required.

Please find below versions being used:
1. java 8
2. datanucleus-api-jdo-5.2.4
3. datanucleus-core-5.2.3
4. datanucleus-rdbms-5.2.3

Thanks.


Andy
 
Edited

Hello,
what was in some version from 2010 I've little interest in. You can trace code changes in SourceForge (ancient code) and GitHub (recent code). Likely it is this change.

Perhaps you can provide the stack trace that calls that method and trace it through to when that is ever called, and hence find how whatever it is is handled now? Either way that code was undocumented likely from back in TJDO days, and we don't use DB2, so someone who does use DB2 has to take responsibility for such things if it gets re-included.

Dont know what "is coming as 2147483647" means. It creates your schema with that in a column? something else?


mayank.chawla@...
 

Hello,

Thank you Andy for your response.

It creates your schema with that in a column - yes

I checked the code changes provided by you and it looks like it was removed so that it takes the implementation from base class and if anybody sets some size explicitly then it will be picked or else the default size. I tried adding that method back in the source and  that method(getUnlimitedLengthPrecisionValue) was called from DB2Adapter class. 

I have to configure the precision value for unlimited length string columns, could you please guide how to do that.

Thanks.


Andy
 

You mean, you have a field MYFIELD (with col name MYCOL) of some type that is mapped to BLOB? and if you don't bother specifying the length of the field in metadata then it picks

MYCOL BLOB(2147483647)



Providing basic info would kinda help (like the class/field definition, and the DDL statement!).

And it gets the long number from what is provided by the DB2 JDBC driver presumably (as the precision of that type). If that is "incorrect" then start off by defining what is the output of DataNucleus SchemaTool when run in "dbinfo" mode, which would look like one of the files in https://github.com/datanucleus/datanucleus-rdbms/tree/master/docs .

Anybody can define the "precision" of a field/column in metadata manually via @Column or <column> length/scale.


mayank.chawla@...
 

Thanks for your reply, I was moved to another task so couldn't look around this.

You mean, you have a field MYFIELD (with col name MYCOL) of some type that is mapped to BLOB? and if you don't bother specifying the length of the field in metadata then it picks - Yes, correct

It is a legacy code and not straight forward, there is some code generation logic and further as per meta data provided in code gen,  jdo classes gets generated which further gets enhanced. So, I cannot go and directly add precision.

2147483647 is the default value which gets set if no length has been defined, after adding the code change highlighted by you which was removed in previous version, it is working as expected. Thinking to keep it in the same way. Thank You.



Andy
 

Changing code back to some ancient version on a whim is not an option in a responsible software project. Facts must be provided first, as stated above, that is the prerequisite.