fix bug in the reading from oracle clob #1183
Conversation
There was a problem hiding this comment.
Is the switch to using a callback really needed? If the problem is really just a wrong byte count, couldn't we multiply (divide?) the length by whatever to fix it?
Also, it would be tremendously helpful if you could please add a unit test checking for this problem, i.e. failing now and passing with this fix. Could you please do this? TIA!
If we should avoid the callback we can try OCILobRead2
Ok |
| } | ||
|
|
||
| value.assign(buf.begin(), buf.end()); | ||
| value = std::move ( accumTo ); |
There was a problem hiding this comment.
BTW, this makes no sense, we should just pass value to the callback instead of accumTo directly.
There was a problem hiding this comment.
It's not very nice to mark a comment as resolved when it wasn't addressed at all.
| if (len != 0) | ||
| ub4 amtp = 0; | ||
| ub4 offset = 1; | ||
| char buf[10240] = {}; |
There was a problem hiding this comment.
Why do we use both a buffer and a callback? Shouldn't we not need the buffer any longer if we use the callback?
There was a problem hiding this comment.
oci read into the buffer and callback after
tests/oracle/test-oracle.cpp
Outdated
| TEST_CASE ( "Oracle clob", "[oracle][clob]" ) | ||
| { | ||
| soci::session sql ( backEnd, connectString ); | ||
| std::string testPhrase{ "SystГЁme est ouvert aux requГЄtes d'information" }; |
There was a problem hiding this comment.
Well, first of all, this doesn't really work even with this PR apparently due to this.
Second, any I really don't want to be mean, but just I don't understand how can a so obviously questionable line be added without any comment explaining it. You should know that something so clearly unusual and apparently wrong would raise questions from whoever is reading it, and I can't fathom why you wouldn't want to explain that the string must be wrongly encoded to trigger the bug (if this is how it really is).
|
Using just the function-based part of the test, it's clear that we have an encoding problem here, i.e. at the first glance this has nothing to do with the byte/char mismatch. Moreover, we don't need to use some weird bytes in the string to see it, the same problem happens with just std::string testPhrase{ "Système est ouvert aux requêtes d'information" };too. I.e. it looks like the real problem is that Oracle/OCI doesn't use the correct encoding for the string. |
|
In fact, the same problem happens with a plain I don't know anything about charsets in Oracle, but it looks like we need to specify that we're using UTF-8 somehow. It's pretty weird that this doesn't work out of the box, even though |
There are no problems with varchar2, export NLS_LANG is required on client session
I have changed oracle.sh to use utf-8 encoding |
|
Thanks, I forgot about |
What is the advantage of using a self-made loop over an oci internal loop with the callback? |
I think using both the buffer and the callback is confusing, if the OCI really doesn't allow to do without the buffer in this case, I'd rather avoid defining the callback. I don't know if the behaviour is the same with |
OCILobGetLength and OCILobRead for character LOBs (CLOBs, NCLOBs) uses the number of characters, not bytes. So, there is a bug with buffer array sizing