Hi Mateusz,

2013-03-07 17:37 keltezéssel, Mateusz Loskot írta:
Hi Wacha,

On 7 March 2013 07:09, Wacha Gábor <[email protected]> wrote:
I have a class for which I wrote the necessary type_conversion to load
from and store to the database.

My class has std::pair members, for which I use the following way to
convert:

      static void from_base(values const & v, indicator & ind/* ind */,
              foo & bar {
          pair<char, unsigned int> temp;

          temp.first = v.get<int>("PAIR1");
          temp.second = v.get<int>("PAIR2");
          bar.setPair(temp);
}

And the to_base is similar:

      static void to_base(const foo & bar, values & v,
              indicator & ind) {
          v.set<int>("PAIR1", line.getPair().first);
          v.set<int>("PAIR2", line.getPair().second);

}

When I try to insert to the database, the first element of the pair is
inserted, but the second element becomes zero.
What happens?



I can't reproduce your problem in current Git master,
but perhaps I'm not testing exactly your case.
My version of test is attached in .cpp file or view gist of it here
https://gist.github.com/mloskot/5109226

If I misunderstood your case, can you post similar compilable sample with yours?
Also, please give exact version or SHA revision of SOCI you're using next time.
Little things, but usually shorten time-to-{test|answer} greatly.

I am using git master. The strange thing is that this code snippet I sent you does not seem to reproduce the problem, I will try to dive into it and write a test case. The failing code is a bit too complex to upload, I will try to simplify it. It seems that I've not identified the source of the bug correctly.

Actually when inserting happens, after each v.set(...)
call the from_base is called.
Yes.

I put the first element of the pair into the database, then from_base
reads it back from values, and (because values does not yet contain the
PAIR2 value) sets the second value to zero.
Then with the call of v.set("PAIR2",...) it sets the value in the
database to zero (or the default value).

Should this happen? Is this a bug or it is mentioned somewhere in the
documentation?

Also, why should to_base call from_base after every call of values::set?
It seems to be a great performance hit for me.
This is a good question and it caused confusions (see issues linked below) to
users as well as to other SOCI developers

Short answer is, this particular conversions occur is "by design".
Longer answer will follow as I'm going to explain it in the documentation
when I find some time.



Meanwhile, here is recent bug report related directly to this behaviour
and reported for broken stored procedures with IN/OUT parameters:

https://github.com/SOCI/soci/issues/81

where you will find some linked commits removing this "double conversion"
as optimisation. I fixed that problem restoring this "double conversion"

https://github.com/SOCI/soci/pull/88/

Thanks for your answer. This "double conversion" still seems to be a "flaw" in the design, when one has a database with a lots of fields then it can slow down the database insert process.

Best regards,

Gabor Wacha


If you look at changes in  files
src/core/type-conversion.h
src/core/use-type.cpp
you will see two longish comments that explain why we need to perform
convert_from_base() on data bound for use()

I hope this will clarify it better.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net


------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev


_______________________________________________
soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users


--
Üdvözlettel,
Wacha Gábor

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users

Reply via email to