GNOME Bugzilla – Bug 662922
GdaBinary data is written (or maybe read) to the database with escape characters
Last modified: 2011-11-03 21:39:03 UTC
Created attachment 200162 [details] test_libgda_binary.c This test case shows that data written to the database is not the same as the data read back, at least with PostgreSQL. I think this started happening fairly recently. I noticed that I could no longer get correct image data to show in Glom.
This test case has this output: original 0: ch_read=92, ch_original=255 original 1: ch_read=51, ch_original=216 original 2: ch_read=55, ch_original=255 original 3: ch_read=55, ch_original=224 original 4: ch_read=92, ch_original=0 original 5: ch_read=51, ch_original=16 original 6: ch_read=51, ch_original=74 That 92 is the \ character, so I guess it is writing (or converting to, after reading) the escaped numeric syntax for each character of the original.
I could not reproduce the problem with your test case. I've tried with glom's embedded PostgreSQL server and with another server; in all cases the blob read is the same as the written one. Could you be more specific on the versions of Libgda and the PostgreSQL server you are using for this test?
(In reply to comment #2) > I could not reproduce the problem with your test case. I've tried with glom's > embedded PostgreSQL server and with another server; Thanks for taking the time do that. By the way, I now have a test for this in Glom's "make check", though it involves lots of Glom code in that case too. > in all cases the blob read > is the same as the written one. Could you be more specific on the versions of > Libgda and the PostgreSQL server you are using for this test? I'm using libgda from git master (5.0.0) and PostgreSQL 9.1. I can reproduce it on Ubuntu Oneiric and Fedora 16, which both have PostgreSQL 9.1 by default. Maybe I can test it using PostgreSQL 8.4 on Ubuntu - I will try.
Actually, I guess that it is caused by a change of output format in PostgreSQL 9.0, mentioned here: http://www.postgresql.org/docs/9.1/static/datatype-binary.html
You were right, the problem was caused by the new HEX representation that comes as a default with PostgreSQL >= 9. Can you check the bug has been corrected as per commit http://git.gnome.org/browse/libgda/commit/?id=c05d146631356f937e04a29171df25fc4b5654c5 ?
Thanks. The test case now passes. However, I can't check yet that it fixes my problem in Glom, because as a side-effect, in Glom, I'm now seeing unquoted text values in where clauses, after setting them with gda_sql_builder_add_expr_value(), causing invalid SQL to be generated. However, I have not yet managed to reproduce that in a simple C test case. I will keep trying.
Created attachment 200453 [details] test_libgda_unquoted_where_value.c This simple test case shows the problem. It shows this warning: ** WARNING **: gda_connection_statement_execute_select() failed: column "something" does not exist LINE 1: ...ngs"."name" FROM "songs" WHERE "songs"."name" = something ^
Ok, can you now check with commit http://git.gnome.org/browse/libgda/commit/?id=a8ebe53b8619ccdc8b649d5aaed2a656df87991c ? Vivien
Yes, it's all working again now. Many thanks. Another tarball release would be nice so Glom can depend on this, if possible. By the way, the SQLite provider seems to have a long-standing problem with GdaBinary values, but I will try to create a test case.
(In reply to comment #9) > By the way, the SQLite provider seems to have a long-standing problem with > GdaBinary values, but I will try to create a test case. Actually, I think the problem now is something that has started fairly recently. Filed in bug #663357 .