It would be nice if I could write something like this:
int main()
{
soci::row r;
soci::session sql( mysql, "db=test user=root" );
sql << "SELECT value FROM table", into( r );
std::cout << "value = " << r.get<soci::any>( 0 ) << std::endl;
std::string str_value = r.get<soci::any>( 0 );
long int_value = r.get<soci::any>( 0 );
soci::any v1;
sql << "SELECT value FROM table", into( v1 );
}
For this purpose we should have some class like this:
namespace soci
{
struct any
{
bool empty() const { returns true if it is NULL; }
operator int() const {}
operator std::stirng () const {}
friend std::ostream& operator << ( std::ostream&, const any& );
// and so on...
};
}
Users might define their own converters:
struct UserDefined
{
UserDefined( const soci::an& );
};
Does anyone have any objection?
On 07/02/2012 04:47 AM, Pawel Aleksander Fedorynski wrote:
> Hey,
>
> Let me add my two cents. In the MySQL backend, the type INT UNSIGNED
> (four byte unsigned integer) was first mapped to dt_long_long. Which
> was consistent with the treatment of other unsigned types, (CHAR,
> SHORT and INT24) which were promoted to a signed 4-byte dt_integer,
> which seemed like a reasonable thing to do.
>
> But recently, Michael Evdokimov reported a bug which had to do with
> the lack of support for BIGINT UNSIGNED (eight byte unsigned integer.)
> Since we have no integer type larger than 8 bytes, I had to map
> BIGINT UNSIGNED to dt_unsigned_long_long. So then it seemed more
> consistent to change the mapping for INT UNSIGNED from dt_long_long to
> dt_unsigned. I don't feel strongly about it and if you think
> dt_long_long was a better choice I can change that back.
>
> I do think that it would be a mistake to map INT UNSIGNED to a
> four-byte signed int, since then we would be corrupting values larger
> than 2147483647. I am definitely in favor of using 64-bit ints (ie
> long long) instead, if we were to stick with using only signed types
> whenever possible.
>
> To answer your question about how existing application code might be
> affected by these changes, consider the following example:
>
> #include <exception>
> #include <iostream>
> #include "soci.h"
> #include "soci-mysql.h"
>
> using namespace soci;
> using namespace std;
>
> int main()
> {
> session sql(mysql, "db=test user=root");
>
> sql << "drop table if exists soci_test";
> sql << "create table soci_test(val int unsigned)";
> sql << "insert into soci_test set val = 123";
> rowset<row> rs = (sql.prepare << "select val from soci_test");
> for (rowset<row>::const_iterator it = rs.begin(); it != rs.end(); ++it) {
> const row& v = *it;
> try {
> cout << v.get<long>(0) << endl;
> } catch (const exception& e) {
> cout << e.what() << endl;
> }
> try {
> cout << v.get<unsigned long>(0) << endl;
> } catch (const exception& e) {
> cout << e.what() << endl;
> }
> try {
> cout << v.get<long long>(0) << endl;
> } catch (const exception& e) {
> cout << e.what() << endl;
> }
> }
> }
>
> This code prints:
>
> std::bad_cast
> 123
> std::bad_cast
>
> when built against the latest version in git, but before I made the
> change today it would have printed:
>
> std::bad_cast
> std::bad_cast
> 123
>
> and using soci-3.1.0 (current stable version, before I added support
> for INT UNSIGNED) it the output is:
>
> 123
> std::bad_cast
> std::bad_cast
>
> I think that's what Neil meant when he wrote that the code is very
> fragile. I agree with this, we should probably make row::get<> more
> forgiving.
>
> Thanks,
>
> Aleksander
>
> On Tue, Jun 19, 2012 at 10:00 AM, Vadim Zeitlin <[email protected]> wrote:
>> On Mon, 18 Jun 2012 20:09:43 +0100 Neil Morgenstern
>> <[email protected]> wrote:
>>
>> NM> I don't think you can just rip it out of the code because people may well
>> NM> be using code relying on it being there.
>>
>> It is defined in a private soci-backend.h header, is it really a serious
>> concern that some code using undocumented symbols from this header might be
>> broken? Moreover, how exactly would it be used anyhow? I don't see any
>> non-artificial way to make use of it outside SOCI, do you?
>>
>> IMHO the only thing that matters is that the code using parameters of
>> all primitive types (including unsigned ones) should continue to work and
>> this would be the case.
>>
>> NM> I do remember wishing that in parts the code was less fragile on type and
>> NM> we had to modify our code to make it so - actually most of the code was
>> NM> using long as the integral type so we essentially allowed it for any
>> NM> integral value that could convert to long without overflow.
>>
>> Well, unsigned long could be converted to long, as I wrote. IMO it's much
>> better to represent it in the same way as long at the database level
>> instead of using int64 for it.
>>
>> Anyhow, please let me know how would any existing code be broken by the
>> proposed change.
>>
>> TIA,
>> VZ
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Soci-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/soci-users
>>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Soci-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/soci-users
--
Best regards, Michael Evdokimov
Network Solutions, Moscow, Russia, Office: +7-495-7950677, Mobile:
+7-963-6054013
Web: www.lanbilling.ru, www.lanbilling.tv, www.helpdesk2.ru
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
