Character implementation in JDBC driver does not support space (ASCII-32)

[GoogleCodeExporter]

What steps will reproduce the problem?
(simple SQL scripts or simple standalone applications are preferred)
1. Use the JDBC driver to write a space character to a table with a column that 
is a CHAR(1)
2. restart db (to clear any caching of the data)
3. Use the driver to retrieve the value.

What is the expected output? What do you see instead?
I expected to be able to get the space char from the DB, instead I get an empty 
string

What version of the product are you using? On what operating system, file
system, and virtual machine?
I am using the version that is distributed with Eclipse EMF/CDO

Do you know a workaround?
Our work around was to change our EMF model to be able to define the column as 
a VARCHAR(1) which works fine.

What is your use case, meaning why do you need this feature?
Our application is modeling key strokes and persists each key up and down 
event.  This includes modeling the key selected.  Every character works 
-except- for space.  The space key is significant for us.

How important/urgent is the problem for you?
Our application does not actually start without our work around.  It would be 
nice to have this fixed quickly but we would also need CDO to upgrade the 
version of H2 shipped.

Please provide any additional information below.
I did take a look at the source code and found that ValueStringFixed is a 
smoking gun.  This class has a method trimRight(..) which will remove all 
spaces to the right upon retrieval from the DB.  Since we only have spaces in 
the column, all data is removed.  

On a side note, it looks like the method does not completely implement trim 
anyway since it only removes spaces and not all whitespace.  There is a static 
method Character.isWhitespace(..) that could be used to check is a char is 
whitespace.  That said, you would have the problem listed in the bug for all 
whitespace if the method checked for all whitespace.

Original issue reported on code.google.com by rbraithw...@gmail.com on 27 Dec 2012 at 8:22

[GoogleCodeExporter]

CHAR is implemented as a workaround for existing (old) applications, and it 
works well for this use case. Changing the implementation would break those 
applications.

I suggest to use VARCHAR instead.

Original comment by thomas.t...@gmail.com on 17 Jan 2013 at 8:09

• Changed state: WontFix

[GoogleCodeExporter]

Um, one of your biggest users (CDO from Eclipse which ships natively H2) 
specifically uses a CHAR(1) for their EChar datatype.  Are you suggesting that 
an entire EMF datatype not be used?  I tried to force this in EMF/CDO and it 
would not let me.

To me it seems like a simple fix to ensure that you have at least 1 char in the 
string returned.  Otherwise, I will need to change to a different database that 
has the proper support for CHAR(1).

Original comment by rbraithw...@gmail.com on 17 Jan 2013 at 8:50

[GoogleCodeExporter]

Is there a issue logged with EMF/CDO? If yes could you add a link?

I would prefer if this is changed in EMF/CDO.

Original comment by thomas.t...@gmail.com on 12 Feb 2013 at 5:59

[GoogleCodeExporter]

I created an EMF bug the same day.  They are doing a work around and it has 
already been implemented. 

I do not understand your reluctance to fix this in H2.  A single space is 
completely valid to have and having EMF need to recognize an empty string to 
really be a single space is hacky and can become problematic.  I have looked at 
the offending code.  All you need to do is not strip all spaces if there is 
only a single space.

Original comment by rbraithw...@gmail.com on 13 Feb 2013 at 2:47

[GoogleCodeExporter]

Hi,

I don't want to use that as an excuse really, but MySQL also strips the space, 
so that:

drop table test;
create table test(id int, name char(1));
insert into test values(1, ' ');
select length(name) from test;

in MySQL returns 0. See also http://sqlfiddle.com/

For MS SQL Server, select len(name) from test also returns 0, however it seems 
the space is sometimes not stripped.

And for the following case, even PostgreSQL strips all spaces, for all rows:

create table test(id int, name char(10));
insert into test values(1, 'test   ');
insert into test values(2, '   ');
insert into test values(3, ' ');

So let's say behavior is a bit weird with the CHAR data type.

Original comment by thomas.t...@gmail.com on 13 Feb 2013 at 6:17