Hi Andy, Erik,

we have a lot of derby errors "ERROR 22001: A truncation error was
encountered trying to shrink CHAR 'XXX' to length 1."

I analysed the problem writing a little Java program that uses JDBC
directly. The program inserts a row into a table having a single CHAR(1)
column. The program uses a prepared statement and binds a Java character
to it using different methods:

1) PreparedStatement.setShort
2) PreparedStatement.setInt
3) PreparedStatement.setObject
4) PreparedStatement.setString

Note: There is no PreparedStatement.setChar. The program runs with
different Java characters:

If the Java character is greater or equal 0xA, then 1), 2), 3) fail.
If the Java character is less than 0xA and greater or equal 0x0, then
only 3) fails.

When 1) and 2) fails, then the exception message is the same as above.
3) always fails with "An attempt was made to get a data value of type
'CHAR' from a data value of type 'java.lang.Character'." (I do not
understand this message). 4) is always sucessfull.

It seems that 1) and 2) fail, because Derby stores numbers in string
representation if the database column type is CHAR, e.g 0xA => "10".

So, I wonder if JPOX uses 1) or 2) when binding a single character? This
would be an explanation for 25 error messages. Can you please check
that? I think the right method to use is 4).

Regards,
Michael
--
-------------------------------------------------------------------
Michael Watzek                  Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de        Buelowstr. 66
Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
Fax.:  ++49/30/217 520 12       http://www.spree.de/
-------------------------------------------------------------------

[ Post a follow-up to this message ]

Hi Michael,

> we have a lot of derby errors "ERROR 22001: A truncation error was
> encountered trying to shrink CHAR 'XXX' to length 1."

I've never seen one of these in our testcases, so we've got some difference 
in
how the TCK is specifying things and how we've done it.

> I analysed the problem writing a little Java program that uses JDBC
> directly. The program inserts a row into a table having a single CHAR(1)
> column. The program uses a prepared statement and binds a Java character
>   to it using different methods:
>
> 1) PreparedStatement.setShort
> 2) PreparedStatement.setInt
> 3) PreparedStatement.setObject
> 4) PreparedStatement.setString

What type is the Java type and what type is the DB column ? (and is there a
jdbc-type specified in the MetaData?). Give an example of a Java field, its
MetaData entry, and the RDBMS column type and we should be able to isolate
this [OK, I could run the TCK and try to find one, but since you have th
ese
fresh in your memory its easier to ask you :-)]

JPOX could use many different JDBC methods depending on what Java type and
what RDBMS type so it depends on your situation. For example :-
Java=char/Character, RDBMS="INTEGER", uses JDBC setInt()
Java=char/Character, RDBMS="CHAR", uses JDBC setString()


--
Andy

[ Post a follow-up to this message ]

Hi Andy,

I extended the test program to make objects persistent using JPOX in
addition to the JDBC test I described below:

There is a persistence capable class having a field of type "char".
There is a table having a single column of type "CHAR(1)". The orm
metadata for this class specifies a field mapping from the "char" field
to the "CHAR(1)" column. The orm column attribute "jdbc-type" is
omitted. Thus, the JPOX default is used.

When an object is made persistent using that mapping, then Derby throws
error 22001 (see below).

But if the mapping contains the orm column attribute "jdbc-type" setting
it to "CHAR" explicitly, then Derby does not throw that error. Instead,
pm.makePersistent succeeds.

It seems, that JPOX does not default orm column attribute "jdbc-type" to
"CHAR" if the field is of type "char" or "java.lang.Character". Instead,
JPOX defaults to a numerical type, e.g. "INTEGER". Can you verify that?

Craig,

the spec specifies in chapter 18.5:

"The jdbc-type attribute declares the type of the column in the
database. This type is defaulted based on the type of the field being
mapped."

Does this mean, that an implementation may choose for an default?

Another question: The TCK orm metadata does not specify column attribute
"jdbc-type". Thus, implementations use their default when the TCK runs.
Does it make sense, to add the jdbc type to all column attributes
ensuring that the mapping fits to the database schema?

Regards,
Michael

> Hi Michael,
>
> 
>
>
> I've never seen one of these in our testcases, so we've got some differenc
e in
> how the TCK is specifying things and how we've done it.
>
> 
>
>
> What type is the Java type and what type is the DB column ? (and is there 
a
> jdbc-type specified in the MetaData?). Give an example of a Java field, it
s
> MetaData entry, and the RDBMS column type and we should be able to isolate
> this [OK, I could run the TCK and try to find one, but since you have 
these
> fresh in your memory its easier to ask you :-)]
>
> JPOX could use many different JDBC methods depending on what Java type and
> what RDBMS type so it depends on your situation. For example :-
> Java=char/Character, RDBMS="INTEGER", uses JDBC setInt()
> Java=char/Character, RDBMS="CHAR", uses JDBC setString()
>
>


--
-------------------------------------------------------------------
Michael Watzek                  Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de        Buelowstr. 66
Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
Fax.:  ++49/30/217 520 12       http://www.spree.de/
-------------------------------------------------------------------

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

> > "The jdbc-type attribute declares the type of the column in the 
>
> That was not the intent. The intent was that the JDBC type would be
> obvious. ;-) And the "obvious" jdbc-type for char and Character is
> CHAR. I'll raise this issue with the JDO experts to be sure.

Well in the case of a char it is, but in the case of a Java double for
example ? It all depends on the RDBMS. Some RDBMS support DOUBLE, some
DECIMAL, some NUMERIC, some have other types ...

--
Andy
Java Persistent Objects - JPOX

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

> > Well in the case of a char it is, but in the case of a Java double for 
>
> This is the jdbc-type ("generic sql type"), not the sql-type we're
> talking about (there is a separate sql-type that the user can specify
> if they want to get database specific).
>
> The idea is that the user could override the jdbc-type if necessary,
> and the jdo impl would use jdbc-type plus length plus nullability to
> map to a natural sql-type that is database specific.

I'm also talking about the jdbc-type (or to be specific javax.sql.Types). So
the JDO impl should always take JDBC Types.DOUBLE when the user has a Java
double field? Many JDBC drivers *don't* provide a type mapping for
Types.DOUBLE (many don't provide support for several of the "standard" JDBC
types).

We've always encouraged our users to specify the jdbc-type if they want thin
gs
to be JDO-impl independent for this very reason.

While a default may make sense so people know what they get if nothing is
specified, there are *a lot* of situations where the JDBC driver doesnt
support a "generic" sql type even

--
Andy
Java Persistent Objects - JPOX

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

Hi Craig,
 
>
> I'm trying to see where the confusion is. The attribute is only
> specified if the user wants to override the default for the field
> type. Is this what you're talking about?

Just trying to understand what you're proposing with respect to how JDO impl
s
decide a "default" RDBMS type. You previously said that your intent of the
spec was that the jdbc-type (when not specified) should be the "obvious one
for the Java type". I was simply pointing out that if the user has a Java
double, then the obvious jdbc-type would be "DOUBLE", and that many RDBMS
dont map that in their JDBC drivers, so what use is that default ?

The origin of the problem Michael reported is down to the lack of a jdbc-typ
e
specification in the metadata, and the fact that JPOX's current "default" fo
r
char is to store it as INTEGER (for whatever reason) - hence why he got the
problem.

We know JPOX's internal type mapping needs more flexibility, but the JDO spe
c
doesn't define what we have to do currently, so our assumption til now was
that the user can define their required type if they have one in mind,
otherwise they take what we give them.



--
Andy

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]