[SOCI-users] How to check if SQL delete from deleted anything?

[Vadim Zeitlin]

 Hello,

 I'm just starting to use SOCI so sorry in advance if I'm missing something
obvious but is there any way to detect if a delete SQL statement affected
any rows? I thought that got_data() would return false if it didn't delete
anything but at least with the ODBC backend this is not the case as it is
always true.

 Looking at the code I see that odbc_statement_backend::execute() always
returns ef_success in this case (as fetch() is not called), but is this
really the right thing to do if the returned value is SQL_NO_DATA? Perhaps
something like this:

--- a/src/backends/odbc/statement.cpp
+++ b/src/backends/odbc/statement.cpp
@@ -157,6 +157,11 @@ odbc_statement_backend::execute(int number)
 SQLCloseCursor(hstmt_);

 SQLRETURN rc = SQLExecute(hstmt_);
+if (SQL_NO_DATA == rc)
+{
+return ef_no_data;
+}
+
 if (is_odbc_error(rc))
 {
 throw odbc_soci_error(SQL_HANDLE_STMT, hstmt_,


should simply be added there?

 And if the code is correct, is there some other way to check whether
anything was deleted or not? get_affected_rows() is not implemented for the
ODBC backend and I can't think of anything else.

 Thanks in advance for any advice!
VZ


pgpwfFDvCQtPt.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] How to check if SQL delete from deleted anything?

[Vadim Zeitlin]

On Thu, 3 May 2012 12:08:29 +0100 Neil Morgenstern 
neil.morgenstern.2...@gmail.com wrote:

NM We had to modify the odbc error in our code to make it more descriptive,
NM i.e. actually give the error message in the what() text.

 Hello Neil,

 This looks like a good idea in its own right but I'm not sure how does it
really help with my question as I definitely don't want to try parsing
what() message to see if anything was deleted. Also, at the moment no
exceptions are being thrown anyhow, even if nothing was deleted so, again,
I'm not sure what do you really propose to do -- throwing an exception in
this case doesn't look like a good idea, if only from the backwards
compatibility point of view.

NM There are a bunch of other fixes you need to make using ODBC, which we got
NM to work with Stored Procedures (but using statement not procedure, in
NM particular calling SQLMoreData (I think that's the call) until you either
NM reach the end of get a column count.

 I'd be interested to knowing which other problems did you fix in the ODBC
backend, do you have your changes available somewhere?

NM Calling SQLFetch is an error if there is no data, i.e. no columns, but is
NM legal if there are simply no rows.

 Sorry if I'm missing something here because I'm not an ODBC expert but how
does SQLFetch() help with deleting rows from the database?

 Anyhow, for now my question remains whether this patch, from my original
post, should be applied:

--- a/src/backends/odbc/statement.cpp
+++ b/src/backends/odbc/statement.cpp
@@ -157,6 +157,11 @@ odbc_statement_backend::execute(int number)
SQLCloseCursor(hstmt_);

SQLRETURN rc = SQLExecute(hstmt_);
+if (SQL_NO_DATA == rc)
+{
+return ef_no_data;
+}
+
if (is_odbc_error(rc))
{
throw odbc_soci_error(SQL_HANDLE_STMT, hstmt_,


It does solve the problem for me but I don't know how do the other backends
behave in this case. If they do return ef_no_data, then this would seem to
be the right thing to do for ODBC too. Does anybody know if they do?

 Thanks,
VZ


pgpi1ubvSuWk1.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[SOCI-users] PATCH: Fix buffer overflow in ODBC backend pre_use()

[Vadim Zeitlin]

 Hello again,

 Currently the code in odbc_standard_use_type_backend::pre_use() can
overflow the buffer for x_stdstring type variables as it's allocated to the
size of the string in prepare_for_bind() but the string value can change
afterwards, e.g. if you do this:

std::string str;
statement st(session);
st.alloc();
st.prepare(query);
st.exchange(use(str));
st.define_and_bind();

str = Hello world!;

st.execute(true);

Granted, this is not a normal use case but it still seems wrong to corrupt
the buffer in this situation. The patch below ensures that the buffer is of
correct size by uncommenting the code that allocated it in pre_use(), it
really must be done there. In fact the allocation in prepare_for_bind() is
almost certainly unnecessary and could probably be just removed but I'm not
sure to understand the code in all details so for now I didn't change this.

 Please let me know if you see any problems with this patch and if it can
be applied to the official version otherwise (or if you prefer to receive
patch submissions in some other way, e.g. via git pull requests).

 Thanks,
VZ

--- a/src/backends/odbc/standard-use-type.cpp
+++ b/src/backends/odbc/standard-use-type.cpp
@@ -189,14 +189,9 @@ void odbc_standard_use_type_backend::pre_use(indicator 
const *ind)
 {
 std::string *s = static_caststd::string *(data_);
 std::size_t const bufSize = s-size() + 1;
-// TODO: this is a hack (for buffer re-size? --mloskot)
-//delete [] buf_;
-//buf_ = new char[bufSize];
-
-std::size_t const sSize = s-size();
-std::size_t const toCopy = sSize  bufSize -1 ? sSize + 1 : bufSize - 
1;
-strncpy(buf_, s-c_str(), toCopy);
-buf_[toCopy] = '\0';
+delete [] buf_;
+buf_ = new char[bufSize];
+strcpy(buf_, s-c_str());
 }
 else if (type_ == x_stdtm)
 {


pgpu4WAYUqZmf.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] How to check if SQL delete from deleted anything?

[Vadim Zeitlin]

On Thu, 3 May 2012 23:43:18 +0100 Neil Morgenstern 
neil.morgenstern.2...@gmail.com wrote:

NM Ok, my SQL isn't that expert but to find out how many were deleted you
NM might:
NM - SELECT @@ROWCOUNT as NumDeleted together with your delete statement which
NM would give you the number of rows deleted as a result set.
NM - Use a stored procedure that does that. Then you come to having to adapt
NM SOCI to stored procedures. Incidentally we did the outbound parameter
NM binding with direct SQLBind and not attempting to support it with SOCI.
NM 
NM Not sure about the syntax if not using a stored procedure.

 Thanks again for your help, Neil, but I still can't help wondering if all
these complications are really needed. E.g. I'm definitely not going to use
stored procedures just for this, I could simply run a select before a
delete instead. And @@ROWCOUNT is interesting but I think it's MS SQL
specific and ideally I'd prefer to keep my code portable to other RDBMS for
as long as I use ODBC backend.

 But mostly I just don't understand why doesn't SOCI use the return code
from SQLExecute() which already contains all the information I need. More I
think about this, more I believe it's just a bug. But I'll try to test with
other backends to see how does it work there to confirm.

 Thanks again,
VZ


pgpELF75y9r7y.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] How to cache prepared statements?

[Vadim Zeitlin]

On Mon, 7 May 2012 20:27:58 +0100 Neil Morgenstern 
neil.morgenstern.2...@gmail.com wrote:

NM They wouldn't be static variables they would be class member variables, so
NM in your case members of MyClass.

 It's true but in my case MyClass is a singleton so there is no essential
difference between using static/global or member variables. The main
problem is that I still need to keep all these extra variables and write
code copying data to/from them instead of using the real data directly.

 It would be really much better if I could keep a prepared statement but
just rebind the variables used in it. I know that it's not impossible to
implement this as (SOCI-inspired, AFAICS) cppdb library does allow it, see
the last example at http://cppcms.com/sql/cppdb/stat.html, but I don't see
how to do it with SOCI yet... I wonder if I'm really the first person to be
trying to do this? If so, why? Am I perhaps missing something and it's
simply not worth trying to cache the prepared statements (e.g. because
database keeps such cache internally anyhow)?

NM If you really are doing this a lot and want to optimise, consider using the
NM vector option.

 I can't do this, the values are read one by one and more or less
unpredictably. I was just trying to save on the statement preparation here
but, again, perhaps it's not really even worth doing it. I still find it
strange if it's really not supported, I was hoping that I was just missing
the right way to do it.

 Regards,
VZ


pgp0RDH4Arlou.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] How to cache prepared statements?

[Vadim Zeitlin]

On Wed, 9 May 2012 11:40:20 +0100 Neil Morgenstern 
neil.morgenstern.2...@gmail.com wrote:

NM This is becoming a discussion though in good programming design and not
NM SOCI itself.

 Yes, but I'd actually prefer to avoid discussing the general design and
keep the discussion centered on just the SOCI-specific stuff. The example
was dramatically simplified just to make my point, there is really no sense
in reading too much into it, it was only meant to illustrate the question.

NM You should use a member variable which should be private. Preferably
NM users of your class will be calling a function not caring how it is
NM implemented at all, so will have no idea that there is SOCI involved
NM and possibly not even know it is writing to a database.

 Yes, absolutely. But, again, please let's not discuss this, this is really
not what my question was about.

NM Incidentally you might wish to measure the performance before you try to
NM optmise because rebinding a parameter is unlikely to be expensive in
NM reality, it is just assigning a value to some local memory and will be
NM trivial in the overall scheme of things.

 Yes, but the question is exactly about how to rebind it. Currently I don't
see any way to do it using SOCI API, hence I need to use some fixed address
(whether it's static, member or global is really irrelevant) and copy
values to/from it. And copying is really not attractive, not because of
performance considerations (which should be trivial), but just because it's
a lot of extra dumb code to write.

NM The overhead of making the call is going to be the main expense and if it
NM is called a lot and you don't need the results written instantly you could
NM buffer a few values up then use the vector method of executing.

 Yes, all completely true. But there are still situations when I access a
table many times during the program life time selecting different elements
from it without knowing which ones in advance, so buffering is not
possible. Preparing the statement is, of course, not very expensive
compared to the cost of database call itself but I still thought that it
would be nice to avoid doing it repeatedly unnecessarily and would prefer
to prepare the statement just once. However doing this without being able
to rebind the variables used in the statement is too inconvenient to
consider.

 So, the question is/remains: is it somehow possible to rebind the
parameters used (in the sense of both used() and into()) by an existing
prepared statement?

 Thanks again,
VZ


pgpvqHs4DlGkC.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[SOCI-users] ODBC backend broken for custom types

[Vadim Zeitlin]

 Hello,

 Sorry about many messages but I keep running into problems with SOCI, at
least when using ODBC backend (I really hope it's exceptional this way, I
hoped to make my life simpler by using only it for the initial development
and testing but perhaps this wasn't such a good idea...).

 The latest one is that the logic of ODBC statement preparation/execution
is simply broken for custom types. Before starting discussing it, let me
say that this clearly has come up before and a patch possibly fixing this
was even applied (c166625a). Unfortunately the patch was reverted later by
an apparently unrelated commit (e5d8124e). And I couldn't find much in a
way of discussion except for this message:

http://www.mail-archive.com/soci-users@lists.sourceforge.net/msg00669.html

which has some tantalizing hints but no real explanation, let alone
solution. So I'm sorry if I'm going to repeat something that was already
said before but at the very least I hope that this time this will remain in
the mailing list archives.


 Anyhow, after this long introduction here is the problem description: when
type_conversion is specialized for some type, the value to be written to
the database is actually stored in 2 places: conversion_use_type::value_
and in its base details::base_value_holder::val_. It is transformed from
the former to the latter by convert_to_base() method which is called by
standard_use_type::pre_use() itself called from statement_impl::execute().
And the problem is that this is too late for ODBC because we call
odbc_standard_use_type_backend::prepare_for_bind() before execute() (from
statement::define_and_bind()) and by this time base_value_holder::val_ is
still empty. So ODBC code calls SQLBindParameter() with size of 1 for it
(it uses for empty string, probably because of trailing NUL concerns). And
while the buffer is resized and filled with the correct value later (patch
http://www.mail-archive.com/soci-users@lists.sourceforge.net/msg00957.html
helps with another bug there but this isn't enough), we don't rebind the
parameter at ODBC level again so it's never used correctly.

 Now I have no idea why do we actually write some junk to the database
instead of writing a single byte but it's clear that the code simply can't
work this way. To give you a simple example, you can't do

boost::optionalstd::string maybeStr;
maybeStr = Hello, SOCI;
session  insert into ... values(:s), use(maybeStr);

currently, it just doesn't work correctly with the ODBC backend.


 A simple solution would seem to call pre_use() from define_and_bind()
instead of doing it from execute() -- then we'd be able to pass the proper
buffer length to SQLBindParameter(). The message from Mateusz above hints
that there are problems with doing it but doesn't say clearly what they are
so I'm a bit lost here.

 If we can't do this, perhaps we could use SQLDescribeCol() to get the max
column length and pass this length to SQLBindParameter(). I didn't test it
yet and I don't know ODBC well at all but I hope this could work. It does
feel like a bad hack though so I'd really like to know why can't we just
call pre_use() earlier. Any thoughts?


 I'm not sure if the real severity of this bug was really understood during
its previous discussions because even Ilia Barahovski who made the patch
fixing it wrote What the patch fixes is an obscure bug -- but it's not
obscure at all. In fact it's pretty catastrophic as it just prevents the
use of SOCI with custom types convertible to strings. To me the ease of
extending SOCI to work with custom types was one of the main reasons for
choosing it in the first place so I really, really hope that this could be
fixed. I'm prepared to spend more time myself on this (I already spent a
few hours just tracking down this bug because it was far from obvious what
exactly went wrong) but I'd really appreciate some advice from the original
library authors just to avoid wasting times on something that can't work.

 Thanks in advance,
VZ


pgpEnOYvZAwHH.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[SOCI-users] Firebird fixes

[Vadim Zeitlin]

 Hello,

 As I'm still struggling with the ODBC backend I decided to see whether
Firebird backend could be used for my testing for now. Initially it didn't
seem so good as it didn't even compile but fixing compilation was simple
enough and other than that it seems to work fine so far, especially
compared to the ODBC backend.

 Below is a pull request for the patches fixing compilation and also
implementing get_affected_rows() that I need for this backend. You may
prefer to not apply the Don't use deprecated isc_interprete() in Firebird
backend. commit as this only works with Firebird 2.x but OTOH I don't
think anybody still uses 1.x and also considering that compilation was
broken for all Firebird versions since several years, it's probably not
such a big problem.

 Anyhow, here they are:



The following changes since commit 20b3a6a09d9129ccda82023a367ef6ae94a6e51e:

  add patch from Olaf Bonorden (2012-05-21 08:32:43 +0200)

are available in the git repository at:

  git://github.com/vadz/soci-experiments.git firebird-fixes

for you to fetch changes up to f2715775459eed8fbb04ee6dc4758389decca300:

  Implement get_affected_rows() for SOCI Firebird backend. (2012-05-23 20:33:14 
+0200)


Vadim Zeitlin (5):
  SOCI Firebird backend compilation fix: don't use x_cstring.
  Fix x_integer handling in SOCI Firebird backend.
  Compilation fix for ISC_STATUS use in Firebird backend.
  Don't use deprecated isc_interprete() in Firebird backend.
  Implement get_affected_rows() for SOCI Firebird backend.

 src/backends/firebird/error-firebird.cpp |6 +++---
 src/backends/firebird/standard-into-type.cpp |   21 ++---
 src/backends/firebird/standard-use-type.cpp  |   15 ---
 src/backends/firebird/statement.cpp  |   58 
--
 4 files changed, 65 insertions(+), 35 deletions(-)


 Please let me know if you prefer the patches to be submitted via email, I
thought it would be more convenient to submit them like this as there is
more than one of them.

 Thanks,
VZ


pgpxFw6xn2eT5.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] PATCH: Fix buffer overflow in ODBC backend pre_use()

[Vadim Zeitlin]

On Fri, 4 May 2012 01:55:44 +0200 I wrote:

VZ  Please let me know if you see any problems with this patch and if it can
VZ be applied to the official version otherwise (or if you prefer to receive
VZ patch submissions in some other way, e.g. via git pull requests).
VZ 
VZ  Thanks,
VZ VZ
VZ 
VZ --- a/src/backends/odbc/standard-use-type.cpp
VZ +++ b/src/backends/odbc/standard-use-type.cpp
VZ @@ -189,14 +189,9 @@ void odbc_standard_use_type_backend::pre_use(indicator 
const *ind)
VZ  {
VZ  std::string *s = static_caststd::string *(data_);
VZ  std::size_t const bufSize = s-size() + 1;
VZ -// TODO: this is a hack (for buffer re-size? --mloskot)
VZ -//delete [] buf_;
VZ -//buf_ = new char[bufSize];
VZ -
VZ -std::size_t const sSize = s-size();
VZ -std::size_t const toCopy = sSize  bufSize -1 ? sSize + 1 : 
bufSize - 1;
VZ -strncpy(buf_, s-c_str(), toCopy);
VZ -buf_[toCopy] = '\0';
VZ +delete [] buf_;
VZ +buf_ = new char[bufSize];
VZ +strcpy(buf_, s-c_str());
VZ  }
VZ  else if (type_ == x_stdtm)
VZ  {

 Just to make sure nobody applies this patch accidentally, let me leave a
note for the posterity in the mailing list archives:

 This patch is wrong, while it fixes the buffer overflow, it also breaks
ODBC parameters binding. The correct patch can be found in the ODBC
backend broken for custom types -- now with the fix message found at
http://www.mail-archive.com/soci-users@lists.sourceforge.net/msg00982.html

 Hope this helps,
VZ


pgpzC0DlCGPYy.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] PATCH: Fix buffer overflow in ODBC backend pre_use()

[Vadim Zeitlin]

On Thu, 24 May 2012 22:31:29 +0100 Neil Morgenstern 
neil.morgenstern.2...@gmail.com wrote:

NM Let's fix this properly. Get rid of these raw pointers and use
NM vectorchar. Ensure it is bound properly too.

 I don't think the code is really going to be simpler with vectorchar.
And there is no better way to ensure that it's bound properly, as you don't
really store strings in this vector (but also e.g. TIMESTAMP_STRUCT), you'd
need to use memcpy() or reinterpret_cast anyhow. SQLBindParameter() is
inherently type-unsafe and this code reflects it.

 I'd consider using some smart pointer class automatically deleting the
buffer but I don't see SOCI using any smart pointers right now and it's not
worth to add another dependency just for this code.

 Regards,
VZ


pgpv2npGDumco.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[SOCI-users] SOCI development (was: PATCH: Fix buffer overflow in ODBC backend pre_use())

[Vadim Zeitlin]

On Fri, 25 May 2012 11:28:49 +0100 Mateusz Loskot mate...@loskot.net wrote:

ML  SOCI doesn't use shared_ptr because it doesn't force you to be using it.
ML  There are some features of boost you can optionally use. shared_ptr is
ML  standard in C++11 but we are not C++11 compliant yet.
ML 
ML Generally, this has been discussed countless of times, on soci-devel
ML and here too, I guess.

 Hello,

 Could you please explain where is soci-devel? I can't find any traces of
this mailing list anywhere.

ML IMHO, anyone here who wants to step up and take ignite any motion in
ML the SOCI development, be encouraged to do so and let's discuss it here.

 Well, without really meaning to do it (I just wanted to use SOCI, not
develop it), I've been doing just this for the last couple of weeks.
One simple patch was applied already (thanks Alex Ott!) and two more, more
important ones, are waiting until somebody can look at them.

 I'll also need to add a method for dealing with sequences/auto-incremented
values to SOCI as it's impossible to get the primary key of a newly
inserted record without something like this. Should I post my proposal for
this here?

 I also might implement support for caching prepared statements, i.e. for
allowing to rebind their parameters. Since posting my question about this a
couple of weeks ago I discovered that this would be relatively simple to do
but it would require some structural changes to SOCI and I'd rather avoid
doing this unless I really have to.

 Other than that I make no claims to want to work on SOCI but I'd
definitely like to make it work well enough for my current project. And
applying the patch fixing the completely broken behaviour of ODBC backend
would really help (frankly, using vector vs scoped_array vs raw pointer is
of little to no importance compared to rampant memory corruption present in
the code right now).

 Thanks,
VZ


pgph6Ctrvh4qO.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[SOCI-users] RFD: Adding functions for working with auto-incremented values

[Vadim Zeitlin]

 Hello,

 It is common to use auto-generated values for primary keys of the tables
that don't have any natural candidate. There are 2 mechanisms for doing
this depending on the database:

1. Use a sequence. In this case you need to get the next value from the
   sequence and use it in INSERT INTO statement explicitly.

2. Use auto increment field. In this case you don't need to, and at least
   in MS SQL case, actually can't (unless you turn off identity insert
   option), specify the value for the field when inserting it and it's
   automatically generated by the database instead.


Firebird, Oracle, PostgreSQL and several others support (1) while MS SQL
and MySQL (and maybe others too) support (2). This makes writing the code
meant to work with different RDBMS a bit difficult but it may still be
done. In pseudo code:

statement = INSERT INTO T(F1, F2) VALUES(?, ?);
id_value = get_next_sequence_value(sequence_name);
if id_value != -1:
statement = INSERT INTO T(ID, F1, F2) VALUES(?, ?, ?);
statement.use(id_value)

statement.execute()

if id_value == -1:
id_value = get_last_insert_id(tale_name)


 The problem is that currently SOCI doesn't provide the required
get_next_sequence_value() and get_last_insert_id() functions. I could
implement them myself using get_backend() but I think that it would really
make more sense to have them inside SOCI itself as the implementation is
entirely backend-specific. What do you think?

 I'd be able to do it for all the existing backends except SQLite (it
should be possible to implement it there as well using the information from
http://www.sqlite.org/autoinc.html but we don't use SQLite so I don't
really need it there). ODBC one is special because the mechanism to use
depends on the driver used, so I'd need to call SQLGetInfo(SQL_DBMS_NAME)
and check it dynamically. If anybody has any ideas about how to do it
better, I'd like to know about it, of course.

 Thanks in advance for any comments/ideas,
VZ


pgpsGq4BJRdKV.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[SOCI-users] [PATCH] Add support for 64 bit types to ODBC backend.

[Vadim Zeitlin]

 Hello again,

 Here is another relatively trivial patch to the ODBC backend adding
support for 64 bit types:


Support x_long_long and x_unsigned_long_long input and output parameters.

Signed-off-by: Vadim Zeitlin vz-s...@zeitlins.org
---
 src/backends/odbc/standard-into-type.cpp |8 
 src/backends/odbc/standard-use-type.cpp  |   12 ++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/src/backends/odbc/standard-into-type.cpp 
b/src/backends/odbc/standard-into-type.cpp
index d9baeee..fbdde26 100644
--- a/src/backends/odbc/standard-into-type.cpp
+++ b/src/backends/odbc/standard-into-type.cpp
@@ -52,6 +52,14 @@ void odbc_standard_into_type_backend::define_by_pos(
 odbcType_ = SQL_C_ULONG;
 size = sizeof(unsigned long);
 break;
+case x_long_long:
+odbcType_ = SQL_C_SBIGINT;
+size = sizeof(long long);
+break;
+case x_unsigned_long_long:
+odbcType_ = SQL_C_UBIGINT;
+size = sizeof(unsigned long long);
+break;
 case x_double:
 odbcType_ = SQL_C_DOUBLE;
 size = sizeof(double);
diff --git a/src/backends/odbc/standard-use-type.cpp 
b/src/backends/odbc/standard-use-type.cpp
index 8c572ce..d746b53 100644
--- a/src/backends/odbc/standard-use-type.cpp
+++ b/src/backends/odbc/standard-use-type.cpp
@@ -35,6 +35,16 @@ void odbc_standard_use_type_backend::prepare_for_bind(
 cType = SQL_C_ULONG;
 size = sizeof(unsigned long);
 break;
+case x_long_long:
+sqlType = SQL_BIGINT;
+cType = SQL_C_SBIGINT;
+size = sizeof(long long);
+break;
+case x_unsigned_long_long:
+sqlType = SQL_BIGINT;
+cType = SQL_C_UBIGINT;
+size = sizeof(unsigned long long);
+break;
 case x_double:
 sqlType = SQL_DOUBLE;
 cType = SQL_C_DOUBLE;
@@ -97,8 +107,6 @@ void odbc_standard_use_type_backend::prepare_for_bind(
 case x_statement:
 case x_rowid:
 break;
-   case x_long_long: break; // TODO: verify if can be supported
-   case x_unsigned_long_long: break; // TODO: verify if can be supported
}
 }

-- 
1.7.10


pgpnvy6P4e2hN.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[SOCI-users] Yet another ODBC driver problem: SQL type for string fields?

[Vadim Zeitlin]

 Hello,

 I ran into another problem with the ODBC driver when used with MS SQL
server (the problem doesn't arise when using ODBC with Oracle, PostgreSQL
or Firebird): consider a very simple table defined using this MS SQL code:

CREATE TABLE country
(
currency CHAR(3) COLLATE SQL_Latin1_General_CP1_CS_AS NOT NULL, 
id CHAR(2), 
name VARCHAR(50) NOT NULL, 
 CONSTRAINT pk_country PRIMARY KEY(id)
)
GO

It has records like this: (USD, US, USA), (GBP, UK, United
Kingdom), (EUR, FR, France) and so on.

When I do the following:

session s;
string name,
   country(FR);
s  select name from country where id=:country,
 into(name), use(country);

I get the following error with MS SQL ODBC driver (message extracted from
odbc_soci_error thrown by this code):

Statement Execute (ODBC error 42000: [Microsoft][ODBC SQL Server
Driver][SQL Server]The data types char and text are incompatible in
the equal to operator.)

Looking at the code, we use SQL_VARCHAR for string parameters and MS SQL
doesn't seem to like comparing them with CHAR(N) columns. Applying the
following patch makes the problem disappear:

--- a/src/backends/odbc/standard-use-type.cpp
+++ b/src/backends/odbc/standard-use-type.cpp
@@ -63,13 +63,7 @@ void* odbc_standard_use_type_backend::prepare_for_bind(
 case x_stdstring:
 {
 std::string* s = static_caststd::string*(data_);
-#ifdef SOCI_ODBC_VERSION_3_IS_TO_BE_CHECKED
-sqlType = SQL_VARCHAR;
-#else
-// Note: SQL_LONGVARCHAR is an extended type for strings up to 1GB
-// But it might not work with ODBC version below 3.0
-sqlType = SQL_LONGVARCHAR;
-#endif
+sqlType = SQL_CHAR;
 cType = SQL_C_CHAR;
 size = s-size();
 buf_ = new char[size+1];

But I'm not sure if it doesn't introduce some other problems. Does anybody
know what was the original motivation for using SQL_VARCHAR here? FWIW

s  select id from country where name=:name,
 into(country), use(name);

still works after the patch, i.e. comparing SQL_CHAR parameter with VARCHAR
field in the database seems to be OK, unlike the other way around. Can
anybody think of anything else that could be broken by this change?

 Thanks,
VZ


pgpv5xfu7OlfC.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[SOCI-users] ODBC backend post_use()

[Vadim Zeitlin]

 This is getting somewhat ridiculous but it looks that wherever I look at
ODBC backend code I find a problem. The latest one is in its
odbc_standard_use_type_backend::post_use(): what is the point of
overwriting the *input* parameters with the values we have provided for
ODBC driver ourselves? This doesn't seem to make any sense, this data is
never modified by ODBC to the best of my knowledge (again, we're speaking
about SQL_PARAM_INPUT here), so why should we do this? Does anybody know of
any problems that would happen if post_use() part dealing with data is
simply removed?

 I realize that it's probably high time to stop asking questions and just
forget about using ODBC with SOCI completely but perhaps somebody knows the
answer to this one?

 Thanks,
VZ


pgpJddSBuGW08.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] ODBC backend post_use()

[Vadim Zeitlin]

On Mon, 28 May 2012 11:37:32 +0100 Mateusz Loskot mate...@loskot.net wrote:

ML On 28 May 2012 02:48, Pawel Aleksander Fedorynski pfe...@gmail.com wrote:
ML  [+soci-devel]
ML 
ML  Guys: do you think we could just give Vadim write access to git so he
ML  can submit his fixes for the ODBC backend?  It doesn't seem anyone is
ML  in any rush to review them and by the sound of it Vadim by now knows
ML  the ODBC backend as well as anyone or better?
ML 
ML Yes, I think it's a good idea.
ML I suggested Alex to contact Maciej with request to write access
ML So, I don't see any reason why Vadim couldn't do the same.

 Hello again,

 OK, I'll do this, thanks.

ML Vadim:
ML ODBC backend is considered as incomplete. It has been released
ML as proof of concept and IMHO to tell users there is such thing
ML as SOCI ODBC backend and potentially encourage some contributors to update 
it.
ML I want to say, I'm glad you've arrived :)

 I'm always glad to help any open source project I'm using but I must say
I had a really frustrating experience with SOCI so far. And this
frustration is mostly explained by not realizing that ODBC backend was in
such a bad shape. The documentation only says this about sqlite3 and odbc
backends: The following backends are also available, with various levels
of completeness: but doesn't even hint how broken exactly is it. I
definitely expected some things not to work with ODBC but I also expected
to get errors about them, not buffer overflows and junk being written to
the database.

 I think it would be really better to document the current limitations at
e.g. http://soci.sourceforge.net/doc/backends/index.html. FWIW even after
my changes there are still at least a couple of problems remaining:

* Binding by name is not supported.
* vectorlong long is still not supported (should be simple to fix, in the
  same way as I added support for scalar long long parameters).

 
 Regards,
VZ


pgpNEKMe0XSCT.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[SOCI-users] Is soci-devel in use or not? (was: ODBC backend post_use())

[Vadim Zeitlin]

On Sun, 27 May 2012 18:48:05 -0700 Pawel Aleksander Fedorynski 
pfe...@gmail.com wrote:

PAF [+soci-devel]

 Hi,

 Just a question: I tried subscribing to soci-devel but my subscription
request was rejected. So is this list not used at all any more?

 Thanks,
VZ


pgpJm70F6ErK2.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] RFD: Adding functions for working with auto-incremented values

[Vadim Zeitlin]

On Mon, 28 May 2012 10:29:06 -0700 Pawel Aleksander Fedorynski 
pfe...@gmail.com wrote:

PAF   I also wonder where should the new methods be documented. The easy way 
is
PAF  to just do it in the reference section, but nobody is probably going to
PAF  find them there. But I don't see where else to put them, none of the
PAF  existing sections (e.g. Exchanging data or Statements, procedures and
PAF  transactions) seem to fit and creating a new section just for this would
PAF  be strange too as there is so little to say there. Any advice?
PAF 
PAF I'd make it a separate section.  Doesn't have to be long.

 OK, I'll do this, thanks.

PAF     // Functions for dealing with sequence/auto-increment values.
PAF 
PAF     // If true is returned, value is filled with the next value from the 
given
PAF     // sequence. Otherwise either the sequence is invalid (doesn't exist) 
or
PAF     // the current backend doesn't support sequences. If you use 
sequences for
PAF     // automatically generating primary key values, you should use
PAF     // get_last_insert_id() after the insertion in this case.
PAF     bool get_next_sequence_value(std::string const  sequence, long  
value);
PAF 
PAF     // If true is returned, value is filled with the last auto-generated 
value
PAF     // for this table (although some backends ignore the table argument 
and
PAF     // return the last value auto-generated in this session).
PAF     bool get_last_insert_id(std::string const  table, long  value);
PAF 
PAF Looks good.  I would prefer pointers instead of non-const reference
PAF parameters but we should do whatever's consistent with the rest of
PAF SOCI.

 Well, yes, this is exactly the point. I also dislike non-const references
and don't use it in my own projects but I'm just trying to be consistent
here as I think it's even more important. If there is a consensus to switch
from this style and start using pointers for output parameters, I'd be glad
to change this but otherwise I'll leave this like this.


 I also have a question about implementation: for most of the backends I
actually use soci::session to execute some sort of select in the database.
This is a bit strange as currently the session uses the backends but not
vice versa but OTOH it makes the code very simple and short. And to avoid
this dependency (of the backend on the session) I'd need to actually
duplicate the code from backend/foo/statement.cpp because I can't even reuse
a foo_statement_backend without soci::session, i.e. without the dependency
I'd like to avoid. IMHO duplicating the code would be even worse than
having this reverse dependency. The best solution would be to refactor
foo_statement_backend to allow reusing parts of it from foo_session_backend
without involving soci::session itself, but I don't really have resources
for this... So I only see the two choices described above and for now I
chose the simplest one (if laziness is the main virtue of a programmer, I'm
a good one). Does anybody see any problem with leaving it like this or any
better suggestions?

 Thanks,
VZ


pgpD3nJqNfchu.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[SOCI-users] Why does standard_use_type::post_use() need to convert anything?

[Vadim Zeitlin]

 Hello,

 I've found another puzzle in the SOCI code: when you run an insert
statement with some use() parameters of some custom type for which
type_conversion is specialized, the values are correct converted to the
values of the base type, i.e. the type actually used at database level,
in standard_use_type::pre_use(). So far so good.

 However after the statement is executed, standard_use_type::post_use()
calls convert_from_base() to convert the values from the database type to
the custom type and this was totally unexpected to me. Arguably, it's not a
problem on its own but why on earth would SOCI need to do this? It just
seems absolutely wasteful and unnecessary. Or am I missing some case in
which it isn't?

 Can use() parameters actually be modified? I hope not but I've been
surprised by SOCI before...

 As usual, thanks in advance for any words of wisdom,
VZ


pgplSrYyLhxvF.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[SOCI-users] Why do we need x_unsigned_long?

[Vadim Zeitlin]

 Hello,

 The handling of long values has been recently changed to map to either
x_integer or x_long_long SOCI internal type depending on sizeof(long) in
the program. But unsigned long remains mapped to its own special
x_unsigned_long type which is always mapped to 64 bit long long
(SQL_BIGINT) in ODBC backend. This is inconsistent: not only unsigned long
is treated completely different from long, but it's also handled in a very
different way from other unsigned types such as unsigned short and
unsigned int which don't have any special exchange type defined for them.

 Moreover, looking at the code dt_unsigned_long is only used in 2 places:
in PostgreSQL and SQLite backends. In the former it's used to represent an
OID which is always 32 bits so it would really make much more sense to use
x_integer for it (as SOCI clearly relies on sizeof(int)==4 anyhow). For
SQLite I'm less sure but it seems that handling unsigned int as int is
at least as good as handling it as unsigned long -- and, as I said above,
more consistent.

 So what about simply removing dt_unsigned_long and x_unsigned_long? AFAICS
they're quite unnecessary, inconsistent with the other types and currently
broken in ODBC (because unsigned int definitely shouldn't be mapped to 8
byte SQL_BIGINT).

 Are there any objections to doing this? Would it break anything?
VZ


pgpGZdtkv92ox.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[SOCI-users] Is it correct to silently ignore truncations?

[Vadim Zeitlin]

 Hello again,

 Currently if a select statement results in a null value and no indicator
is defined for the corresponding output parameter, a Null value fetched
and no indicator defined. exception is thrown. I like this very much as it
doesn't allow you to simply ignore nulls while still letting you to handle
them easily just by providing an indicator.

 However for some reason the same logic is not used for truncations. If
either output or input parameter is truncated (the latter happens in
insert/update instead of select), this is recorded in the associated
indicator, if any, but if there is no indicator the truncation is silently
ignored.

 I wonder if this is really correct. It is inconsistent with null handling
and also dangerous (as half an hour spent on tracking a bug due to not
noticing that a truncation happened in my code attests). Shouldn't an
exception be thrown if a value without an indicator is truncated?

 This would clearly be backwards incompatible as previously working code in
which truncations occurred would now start throwing exception but hopefully
the reason for this change in behaviour shouldn't be difficult to find so
maybe it's still worth doing?

 What do you think?
VZ


pgpQcyLleF8gM.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] Why do we need x_unsigned_long?

[Vadim Zeitlin]

On Mon, 18 Jun 2012 20:09:43 +0100 Neil Morgenstern 
neil.morgenstern.2...@gmail.com 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


pgpoWqpiW8flG.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] Why does standard_use_type::post_use() need to convert anything?

[Vadim Zeitlin]

On Tue, 19 Jun 2012 22:44:10 -0700 Stephen Hutton shut...@featurecomplete.com 
wrote:

SH   Can use() parameters actually be modified? I hope not but I've been
SH  surprised by SOCI before...
SH 
SH If recall correctly, this is for binding to stored procedure out
SH parameters.

 But shouldn't into() be used for out parameters? Perhaps this could be
useful for in/out parameters but I don't even know if such thing is
supported by SOCI -- is it?

 ODBC backend definitely doesn't support this and use SQL_PARAM_INPUT for
use() input parameters so at least for it this convert_from_base() call is
perfectly useless (and not always harmless).

 I didn't examine all the other backends yet but from a quick look at them
it doesn't look like they support input/output parameters neither. Does
anybody know more about this?

 Thanks,
VZ


pgp9bHdRkqAdP.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] Why does standard_use_type::post_use() need to convert anything?

[Vadim Zeitlin]

On Sun, 24 Jun 2012 23:59:58 -0700 Stephen Hutton shut...@featurecomplete.com 
wrote:

SH On Wed, Jun 20, 2012 at 3:45 AM, Vadim Zeitlin vz-s...@zeitlins.org wrote:
SH 
SH  On Tue, 19 Jun 2012 22:44:10 -0700 Stephen Hutton 
SH  shut...@featurecomplete.com wrote:
SH 
SH  SH   Can use() parameters actually be modified? I hope not but I've been
SH  SH  surprised by SOCI before...
SH  SH
SH  SH If recall correctly, this is for binding to stored procedure out
SH  SH parameters.
SH 
SH   But shouldn't into() be used for out parameters? Perhaps this could be
SH  useful for in/out parameters but I don't even know if such thing is
SH  supported by SOCI -- is it?
SH 
SH Yes, it's precisely for in/out parameter support.
SH http://soci.sourceforge.net/doc/exchange.html
SH 
SH It is still possible to provide const data for use elements. Note that
SH some database servers, like Oracle, allow PL/SQL procedures to modify their
SH in/out parameters - this is detected by the SOCI library and an error is
SH reported if the database attempts to modify the use element that holds const
SH  data.

 Thanks, this was not at all obvious to me. I also still believe it's a
pretty bad idea to allow modifying use() parameters as I think it could be
unexpected to others as well.

 Please also notice that this definitely doesn't work neither in ODBC nor
PostreSQL backends where the use() parameters are read-only and I think it
doesn't work in any other ones neither. So this really looks like a
leftover from SOCI Oracle origins as it's the only backend for which this
is possible.

 And IMO it should be forbidden and, if necessary, some inout() helper
similar to use() and into() should be added. But I won't change this
myself.

 Regards,
VZ


pgpDmCK4YcqWQ.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] Why does standard_use_type::post_use() need to convert anything?

[Vadim Zeitlin]

On Mon, 25 Jun 2012 15:13:01 +0100 Neil Morgenstern 
neil.morgenstern.2...@gmail.com wrote:

NM Definitely not, out parameters are part of the parameter set, not part of
NM the result set.

 Sorry, definitely not what?

NM When we implemented using SOCI for ODBC for stored procedures (which was
NM supposed to be not supported) we did not find any support for output
NM parameters and we handled these with ODBC direct. In our library we used
NM vectorchar as the type for receiving strings.

 You shouldn't have been able to make this work with use() parameters
without modifying the SOCI sources. They currently unconditionally use
SQL_PARAM_INPUT for binding and only SQL_PARAM_INPUT_OUTPUT parameters can
be modified by ODBC.

NM The ideal way would be use() variations that take (non-const) pointers.

 IMHO this is not ideal at all. When you have a local (hence non-const)
variable that you're writing to the database you absolutely don't expect it
to be modified in the process of being saved.

 Ideal would be to clearly distinguish between input and input/output
parameters and this would require a new syntax.

 Regards,
VZ


pgpZ9L07PoOco.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] Why does standard_use_type::post_use() need to convert anything?

[Vadim Zeitlin]

On Tue, 26 Jun 2012 11:10:14 +0100 Neil Morgenstern 
neil.morgenstern.2...@gmail.com wrote:

NM On Mon, Jun 25, 2012 at 3:29 PM, Vadim Zeitlin vz-s...@zeitlins.org wrote:
NM 
NM  NM Definitely not, out parameters are part of the parameter set, not part
NM  of
NM  NM the result set.
NM 
NM   Sorry, definitely not what?
NM 
NM 
NM output or input/output parameters should not be implemented with into as
NM an into represents a column in a result set, whereas a use represents a
NM parameter.

 I agree that into() is a bad choice for input/output parameters. It's just
that I think that use() is a bad choice too.

NM  NM The ideal way would be use() variations that take (non-const) 
pointers.
NM 
NM   IMHO this is not ideal at all. When you have a local (hence non-const)
NM  variable that you're writing to the database you absolutely don't expect 
it
NM  to be modified in the process of being saved.
NM 
NM An output parameter is intended to be written to. Non-const references
NM would conflict with a lot of the current code. There is currently no use()
NM that takes a pointer so it would be an addition to the code and not break
NM anything that works now.

 Formally you're right but I think the difference between use(T) and
use(T*) is not significant enough to use them for two very different
behaviours.

NM   Ideal would be to clearly distinguish between input and input/output
NM  parameters and this would require a new syntax.
NM 
NM We used an additional flag to indicate if it is input/output rather than
NM just output. In our case though I don't think it ever was. use() could be
NM implemented to take more than one parameter so something like:
NM 
NM   use( T * x, bool isInOut = false, bool isNull = false )

 Sorry but I think this is horrible syntax. First of all, it's completely
unreadable: what does use(x, false, true) mean, quickly? And are sure you
didn't mix it up with use(x, true, false)? Second, it's inconsistent:
SOCI (quite nicely, IMHO) uses indicators instead of boolean isNull
parameters and this is just fine and I don't see any reason to change it.

 Anyhow, once again, I don't have any plans to implement this but I still
believe that the cleanest way would be to add a new inout() function. It's
perfectly backwards compatible and inout(x, indicator) is immediately
understandable, unlike use(x, true, true).

 Regards,
VZ


pgpFcnO0x03bq.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] Review request for pending changes

[Vadim Zeitlin]

On Sun, 8 Jul 2012 13:31:46 -0700 Pawel Aleksander Fedorynski 
pfe...@gmail.com wrote:

PAF --- a/src/backends/mysql/statement.cpp
PAF +++ b/src/backends/mysql/statement.cpp
PAF @@ -377,10 +377,8 @@ void mysql_statement_backend::describe_column(int 
colNum,
PAF  case FIELD_TYPE_CHAR:   //MYSQL_TYPE_TINY:
PAF  case FIELD_TYPE_SHORT:  //MYSQL_TYPE_SHORT:
PAF  case FIELD_TYPE_INT24:  //MYSQL_TYPE_INT24:
PAF -type = dt_integer;
PAF -break;
PAF  case FIELD_TYPE_LONG:   //MYSQL_TYPE_LONG:
PAF -type = field-flags  UNSIGNED_FLAG ? dt_unsigned_long : 
dt_integer;
PAF +type = dt_integer;
PAF  break;
PAF 
PAF This will break test9 in test-mysql.cpp. 

 Sorry about this, I hadn't built MySQL backend initially as I didn't have
the right libraries installed and completely forgot to rebuild with MySQL
backend before submitting the patches :-( I've done this now and corrected
the code as you suggested, thanks for noticing this!

PAF Other than that, looks good to me.

 Thanks a lot for the review!
VZ


pgpqjOB4dGAsV.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[SOCI-users] Add CMake support for Firebird

[Vadim Zeitlin]

 Hello,

 Would anybody be interested in adding support for building Firebird to
cmake build system? I had a look at it and probably isn't that complicated
but I hardly know cmake at all and, frankly, am not very interested in
learning it so it still risks to be beyond my abilities. The only
non-trivial part AFAICS is writing cmake/modules/FindFirebird.cmake which
would define the variables containing Firebird headers and libraries. The
latter is especially unclear to me as normally you should be able to choose
between libfbclient and libfbembed and I just don't know how would this be
handled in cmake.

 It's just a pity that Firebird backend can't be built as part of SOCI when
it seems to be in a reasonably good shape (e.g. still better than ODBC,
even after my fixes/improvements to the latter).

 Thanks in advance for any help with this,
VZ


pgp4nyOAjxfC3.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] Review request for pending changes

[Vadim Zeitlin]

On Tue, 10 Jul 2012 22:48:34 -0700 Pawel Aleksander Fedorynski 
pfe...@gmail.com wrote:

PAF I'm curious, why did you decide not to use the code I suggested for
PAF backends/mysql/statement.cpp?

 I'm sorry, I simply misread the changes in your message. I meant to do
exactly what you suggested but clearly messed things up -- and didn't
notice it because the tests still passed.

PAF All of FIELD_TYPE_CHAR, FIELD_TYPE_SHORT and FIELD_TYPE_INT24 should
PAF fit in four bytes no matter whether they're signed or unsigned, so why
PAF not just identify them as dt_integer?

 No reason at all.

PAF Do you have any objection to me changing it to the version I proposed
PAF in this thread?

 No, not at all, please go ahead -- or I can fix it if you prefer.

 Sorry again for misapplying your changes,
VZ


pgpkIpHk6ovUF.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] SOCI project manager

[Vadim Zeitlin]

On Fri, 20 Jul 2012 09:48:45 +0100 Mateusz Loskot mate...@loskot.net wrote:

ML On 19 July 2012 21:12, Maciej Sobczak p...@msobczak.com wrote:
ML 
ML  I'm pleased to announce that our project member, Mateusz Łoskot, who has
ML  served as a long-time contributor and build manager, has accepted to
ML  become a new project manager.
ML 
ML  Mateusz has a lot of good ideas and enough insider's knowledge to make
ML  them a reality - I wish him a lot of successes and I kindly ask all
ML  other members of the SOCI community to assist him in this takeover.
ML 
ML Thanks very much.
ML Thanks to everyone for great contributions and support.

 Thank you for accepting to become the project manager!

ML I make no huge promises, but I'll do my best.
ML I will appreciate suggestions, comments and critique.

 I think it would be nice to make a new release, if only to verify that the
release mechanism is in place and you have access to everything. But also
to get more testing for the recent changes (notably in the ODBC backend)
and fix any bugs discovered in them as quickly as possible.

 Thanks again and good luck!
VZ


pgpocIzGGPDbc.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] Character Set

[Vadim Zeitlin]

On Thu, 30 Aug 2012 12:38:26 -0400 Candy Chiu candy.chiu...@gmail.com wrote:

CC I have successfully compiled soci and soci-odbc using Visual Studio 2010.
CC  I managed to connect to a DB server and retrieve some data.  Everything
CC worked out well, except I had to change the Character Set property of the
CC project from Use Unicode Character Set to Use Multi-Byte Character Set
CC to get the code compiled.  Since I don't have much experience with the
CC character sets, I am a little leery of changing the default value.  Would
CC someone provide some insights into why the Multi-Byte Character Set is
CC required?  If it is something easy to fix, I am glad to do it.

 Unfortunately this is not something easy to fix. You have to build any
code using SOCI in MBCS, i.e. non-Unicode, mode as SOCI doesn't support
Unicode, at least not in the Windows sense of the word where Unicode means
wchar_t/UTF-16 (you can work with UTF-8 strings in the database with SOCI,
of course, but this doesn't count as Unicode under Windows).

 Regards,
VZ


pgpRm3iobNPNR.pgp
Description: PGP signature
--
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
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] SOCI // MySQL // failed test case 4

[Vadim Zeitlin]

On Thu, 27 Sep 2012 19:50:08 +0400 Sergei Nikulov sergey.niku...@gmail.com 
wrote:

SN So it can be MSVS2010 issue.
SN Can anybody confirm?

 Microsoft CRT has known issues with converting NaNs and infinities to/from
strings and behaves differently from most (all?) Unix libc implementations,
so I'm almost sure it is indeed MSVS-specific. However you can't change its
CRT behaviour so this still needs to be worked around somehow.

 Regards,
VZ


pgpXX8Zzd9tPv.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html___
Soci-users mailing list
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] ODBC: adding an accessor to retrieve the completed connection string?

[Vadim Zeitlin]

On Tue, 18 Sep 2012 18:31:49 +0200 I wrote:

Me  So basically instead of just ignoring the string returned by
Me SQLDriverConnect() in odbc_session_backend ctor I'd like to store it in a
Me member variable and add a get_connection_string() accessor to
Me odbc_session_backend class.
Me 
Me  Would there be any objections to committing such a patch? Or suggestions
Me about how to do it better/outside of SOCI?

 For the reference, I've just committed this change, see

https://sf.net/p/soci/code-0/ci/84ce53d9716eb747105eb14aa8e21f621365f7e5/

 As usual, please let me know about any problems,
VZ


pgpEPazbgEBJP.pgp
Description: PGP signature
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev___
Soci-users mailing list
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] Add CMake support for Firebird

[Vadim Zeitlin]

On Mon, 1 Oct 2012 23:16:11 +0400 Sergei Nikulov sergey.niku...@gmail.com 
wrote:

SN Here the patches for enabling Firebird backend in cmake.
SN I've tested it on Windows 7 and Fedora Linux 16.

 Thanks a lot, I'm going to test and apply them soon. I'll try to modify
the cmake files to support fbembed too though, as I'm mostly interested in
using it and not the full fbclient. Unfortunately I don't know how to
implement the option allowing to choose between using one or the other,
would you know how to do this by chance?

SN The problem is - src/backends/firebird/test/test-firebird.cpp need to be
SN updated. Currently it failed to compile.
SN 
SN I suspect some interface issues. But unfortunately I have no time to look
SN at it. Maybe later.

 What about the cstring inclusion addition, why is it needed exactly? I can
compile Firebird backend just fine without it.

 Thanks,
VZ


pgpviHtLaxZp6.pgp
Description: PGP signature
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev___
Soci-users mailing list
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] Commit odbc backend updates

[Vadim Zeitlin]

On Tue, 23 Oct 2012 14:38:57 -0400 Candy Chiu candy.chiu...@gmail.com wrote:

CC 1. Fixed a bug in preparing a vector of strings for binding.  The current
CC implementation inserted an extra white character to the end of each string.
CC  This error shows up in SQL Server, not in MySQL (via ODBC).

 Hello,

 Setting the indicator to just the string length seems correct to me,
thanks for fixing this!

CC 2. Added support for long long.

 This is definitely nice to have too but notice that I had to work around a
bug in Oracle ODBC driver which silently (i.e. without returning any error)
doesn't support SQL_BIGINT for the scalar types, see the use of
use_string_for_bigint() standard-{use,into}-type.cpp (and full details in
the commit b82364ee). It would be nice to do the same for the vectors too.

 Regards,
VZ


pgpZ1puimJ4rU.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Soci-users mailing list
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] Commit odbc backend updates

[Vadim Zeitlin]

On Wed, 24 Oct 2012 08:44:37 -0400 Candy Chiu candy.chiu...@gmail.com wrote:

CC I am only allowed access to a SQL Server at work, and don't have access to
CC a ORACLE server.

 You could test this case by simply (temporarily) changing
odbc_standard_type_backend_base::use_string_for_bigin() to return true
unconditionally.

 Having written the word test, I also wonder whether the unit tests could
be extended to cover BIGINT support. Or is this already tested somewhere?

 Regards,
VZ


pgpoQBzbaLN1j.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Soci-users mailing list
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] Compiling the example code with Visual Studio 2012

[Vadim Zeitlin]

On Wed, 31 Oct 2012 22:49:10 +0100 Alberto hirakey...@gmail.com wrote:

A I'm new to SOCI, after three days of tryings I finally build it using CMake
A from command line without erros, and now I was trying to compile the
A example code. The problem is it gives me a number of error in the main.obj
A file.

 It looks like you simply don't link with the SOCI libraries -- do you?
VZ


pgpKLAeA8kvQ8.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Soci-users mailing list
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [SOCI-users] Compiling the example code with Visual Studio 2012

[Vadim Zeitlin]

On Thu, 1 Nov 2012 13:16:16 +0100 Alberto hirakey...@gmail.com wrote:

A  It looks like you simply don't link with the SOCI libraries -- do you?
A I got it. This is what I linked:
A C:\dev\soci-3.1.0\core; C:\dev\soci-3.1.0\backends\postgresql;
A C:\dev\PostgreSQL9.2.1\include
A And this is a screenshot of the window with the settings:
A http://puu.sh/1laIs

 Err, these are headers, not libraries. Please check your *linker*
settings.
VZ


pgp3kGXF94wDH.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Soci-users mailing list
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] [RFC] Apply Git branching model

[Vadim Zeitlin]

On Fri, 16 Nov 2012 12:57:23 + Mateusz Loskot mate...@loskot.net wrote:

ML I'm thinking about structuring SOCI development and following
ML some well-known GitHub practices regarding branching, tagging, etc.
ML 
ML I've proposed some ideas as a task here:
ML 
ML https://github.com/SOCI/soci/issues/18
ML 
ML I'd like to ask everyone for comments,especially related to the model
ML outlined in the article linked in the ticket.

 Hello,

 This is not a bad model but I wonder if people are not going to be
confused by the need to make patches to (or make pull requests for) the
development branch instead of the usual master. As it seems that many
(most?) changes to SOCI come from people not working on it all the time, I
think that many of them might not suspect that they need to start from that
branch instead of master.

 So perhaps this model can be used but with master used for development
and some branch with a different name (stable? release?) for the
releases?

 What do you think?
VZ


pgpaywCK7TUTQ.pgp
Description: PGP signature
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] MySQL Query: select round( -111100237735.42999, 2 )

[Vadim Zeitlin]

On Mon, 28 Jan 2013 10:52:44 -0800 Pawel Aleksander Fedorynski 
pfe...@gmail.com wrote:

PAF Do you think we should just allow
PAF 
PAF string s;
PAF sql  select 3.14, into(s);
PAF 
PAF or do you think some new syntax for extra type safety would be warranted,
PAF e.g.,
PAF 
PAF string s;
PAF sql  select 3.14, into_string(s);
PAF 
PAF ?

 I think we do need a different conversion function, i.e. something else
than into, otherwise things will become too confusing (definitely for
humans, possibly for the compiler as well). I'm not sure about the name,
into_string is probably fine but it could be misunderstood as meaning
that there are also into_number and so on while this one is really quite
special. So perhaps into_as_raw_text() or something like this would be more
clear?

 Regards,
VZ


pgprIJbqVVsP8.pgp
Description: PGP signature
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] release plans

[Vadim Zeitlin]

On Thu, 31 Jan 2013 16:18:22 + Mateusz Loskot mate...@loskot.net wrote:

ML Meanwhile, plenty of bug fixes and numerous contributions
ML have been submitted (big thanks to everyone who helped!).
ML So, I'd be inclined to release SOCI 3.2.0 sooner.
ML In fact, the current master compiles, tests run and pass, so
ML as far as I'm concerned, I don't see any major obstacles
ML preventing from pushing the 3.2.0 out soon.

 Hello,

 FWIW I definitely agree that it would be better to release 3.2.0 now
rather than 4.0 later too.

ML I think it's a matter of some kind of vote, so hoping the SOCI team
ML will bump across this post:
ML 
ML Alex, Aleksander, Vadim, Maciej, what you say?

 Personally, I hoped to do several more things with SOCI but unfortunately
got distracted and side-tracked by many other unrelated things and I have
to admit that I probably won't have time to do anything any time soon
anyhow, so it's just not worth it to wait for anything from me, sorry.

 So, again, I'd release 3.2.0 as soon as it's practical and wait until
someone has time to fix the important outstanding bugs and maybe for some
more major features before releasing 4.0.

 Thanks in advance,
VZ


pgp058J4Rj32m.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[soci-users] RFD: how to specify whether ODBC backend should prompt the user?

[Vadim Zeitlin]

 Hello,

 At least under Windows, it's common for the ODBC driver to show a dialog
box to the user asking to enter the missing information when connecting via
a predefined DSN. Typically, the password is not stored in the DSN, where
it could be easily seen, but entered during connection time in this dialog
box.

 Unfortunately this is impossible with SOCI right now as SQLDriverConnect()
call in backends/odbc/session.cpp uses SQL_DRIVER_NOPROMPT as its last
parameter which, as its name indicates, suppresses all prompts. So if the
password is not stored in the DSN, connection simply fails.

 I'd like to be able to at least optionally change this. Unfortunately
there is no really obviously best way to do it as we can't pass any
parameters to the code calling SQLDriverConnect() directly, it only takes
the connection string. So I see several alternatives, let me list them here
with their pros and cons:

0. Just replace the hard-coded SQL_DRIVER_NOPROMPT with equally hard-coded
   SQL_DRIVER_COMPLETE.
   + Simple.
   + Probably more useful than current behaviour by default.
   - In some situations the prompt can really need to be suppressed
 (although I don't really know in which ones and we haven't run into
 any of them while using libodbc++, which uses SQL_DRIVER_COMPLETE, for
 several years before switching to SOCI).

1. Allow having PROMPT=0 or PROMPT=1 in the ODBC connection string.
   + Configurable.
   - Not obviously discoverable and inconsistent with other SOCI backends
 as we'd be using something that is not a valid connection string for
 the underlying library.
   - PROMPT could conflict with driver-defined attribute keywords allowed
 by ODBC specification (standard ones are DSN, UID and PWD).

2. Add static odbc_session_backend::enable_driver_prompt() method which
   would affect the behaviour of the next session::open() calls.
   + Configurable.
   - Introduces a global variable.
   - While not being really inconsistent with the other backends, it's very
 ODBC-specific and wouldn't help if we need to provide any other such
 out of band connection parameters in the other backends.

3. Add some generic way to pass connection parameters other than those
   specific by the connection string. E.g. add an optional
   std::mapstd::string, std::string argument to session::open() which
   would contain arbitrary key/value pairs that would be passed to the
   backend.
   + Generic.
   - Untyped (i.e. too generic) and still difficult to discover.
   - Most complex.


 Which approach do you think would be preferable? Or do you see some other
one, not listed above? I'm leaning towards (2) but not sure at all if it's
really the best idea.


 Also, if any approach other than (0) is chosen, we'd need to decide what
should be the default value of the prompt option. IMHO we should allow
prompting by default, i.e. use SQL_DRIVER_COMPLETE by default, as the
current approach forces people to store the password in clear text in the
registry in the most common case which is hardly ideal from the security
point of view.


 Thanks in advance for any thoughts about this,
VZ


pgpy2mSSLatUT.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] MySQL Query: select round( -111100237735.42999, 2 )

[Vadim Zeitlin]

On Sat, 2 Feb 2013 20:39:00 + Mateusz Loskot mate...@loskot.net wrote:

ML On 29 January 2013 17:40, Pawel Aleksander Fedorynski pfe...@gmail.com 
wrote:
ML  into_as_raw_text() sounds good to me.  The final decision belongs to
ML  Mateusz.
ML 
ML Nah, we should get this as well as other similar things agreed
ML collaboratively, as a team :)
ML 
ML Let's summarise things up, so I'm clear about the idea:
ML 
ML 1. into(sink) stores a value fetched from query results in the sink
ML 
ML 2. into(sink) has some capacity to perform value type to sink type
ML conversion, sort of a type promotion triggered by the difference between
ML value type and sink type.
ML 
ML 3. into(sink) has no capacity to perform advanced explicit conversions if
ML distance between value type and sink type is significant.
ML 
ML We don't want to equip the existing into(sink) machinery with advanced
ML conversion ability because it would easily conflict with the implicit type
ML promotion that's already there.
ML 
ML So, we need a new tool.
ML 
ML I guess, don't need a tool capable to perform any value type to any sink 
type
ML conversion, but any value type to text is sufficient. Thus, we're gonna have
ML single into_xxx(std::string) utility.
ML 
ML Am I getting it?
ML The sink type is hard-wired std::string, right?

 Hello,

 This was exactly what I was proposing, thanks for your nice summary!


ML Regarding name, I don't have a clear winner candidate, but I guess that
ML it should suggest it's related to into():

 Yes, again, I can't but agree.

ML Obviously, there is lots of variants to consider:
ML into_as_raw_text()
ML into_as_text()
ML into_as_raw()
ML into_raw()
ML into_text()
ML into_to_string()
ML into_convert()
ML 
ML I'd also consider name aligned with the C++11 converter std::to_string
ML 
ML into_to_string()

 into + to seems a bit strange to me. As for into_text or
into_string, this seem to easy to confuse with the function for
retrieving a normal field value of a string type, i.e. I could imagine
people using this instead of a simple into() for no good reason. So IMHO
using raw is important. The choice between into_as_raw_text,
into_as_raw and into_raw is, AFAICS, purely subjective and personally I
rather like the latter as it's the shortest while still retaining the
really significant part of the name. But my initial reason for recommending
into_as_raw_text was that

(1) the purpose of this function was not completely obvious
(2) it shouldn't be used very often

and, based on this, it didn't seem like a good idea to optimize its name
for brevity.

 Regards,
VZ


pgpeF2iYfCokp.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] RFD: how to specify whether ODBC backend should prompt the user?

[Vadim Zeitlin]

On Sat, 2 Feb 2013 21:37:58 + Mateusz Loskot mate...@loskot.net wrote:

ML On 31 January 2013 21:11, Vadim Zeitlin vz-s...@zeitlins.org wrote:
ML   At least under Windows, it's common for the ODBC driver to show a dialog
ML  box to the user asking to enter the missing information when connecting 
via
ML  a predefined DSN. Typically, the password is not stored in the DSN, where
ML  it could be easily seen, but entered during connection time in this dialog
ML  box.
ML 
ML  [...]
ML  So I see several alternatives, let me list them here
ML  with their pros and cons:
ML 
ML  0. Just replace the hard-coded SQL_DRIVER_NOPROMPT with equally hard-coded
ML SQL_DRIVER_COMPLETE.
...
ML If you say it's more useful, I see no problem applying this approach
ML straight away even if it's going to be improved in future.

 Well, in my situation it's definitely more useful because we're basically
working with user-defined DSNs which may or may not include login/password
information. I am not completely sure if there are no other situations in
which this behaviour is inappropriate though -- as I wrote, I can't think
of any, but it could be just due to my lack of experience with ODBC.

ML I mean, I have no problem leaving this decision to you.

 I think I might have a problem with this though :-/


ML  1. Allow having PROMPT=0 or PROMPT=1 in the ODBC connection string.
ML + Configurable.
ML - Not obviously discoverable and inconsistent with other SOCI backends
ML   as we'd be using something that is not a valid connection string for
ML   the underlying library.
ML - PROMPT could conflict with driver-defined attribute keywords 
allowed
ML   by ODBC specification (standard ones are DSN, UID and PWD).
ML 
ML My gut feeling says it's not best approach indeed :)

 FWIW we could use something like SOCI_OPTION_PROMPT to reduce (and, in
practice, eliminate) the risk of such conflict. It would still remain ugly
though.

ML  3. Add some generic way to pass connection parameters other than those
ML specific by the connection string. E.g. add an optional
ML std::mapstd::string, std::string argument to session::open() which
ML would contain arbitrary key/value pairs that would be passed to the
ML backend.
ML + Generic.
ML - Untyped (i.e. too generic) and still difficult to discover.
ML - Most complex.
ML 
ML I think this could be a basis for better solution.

 OK, let me try to do this then.

ML It comes down to the decision of what we want to pass as the configuration.
ML The std::mapstd::string, std::string is an obvious choice and with
ML a bit of string-to-type converting internal machinery it would work well.
ML 
ML Disadvantage: users will have to deal with type-to-string conversions
ML on their own.

 Yes, there is that, although to me the lack of type safety is more
important. String conversions are annoying (in C++), but this is not
something that would be used very often, would probably be used half of the
time for parameters which are strings anyhow, so basically I just don't
think it's going to create big problems in practice.

ML Solution: we could add a bit more and provide soci::configuration
ML class mapping std::string key to a T value.

 The trouble is that not all options would use the values of the same type,
so we'd need either a heterogeneous container or use Boost.Any for T and
this IMHO would start getting too complicated for something basically as
simple as this.

ML More advanced solution is to use Boost.PropertyTree as configuration
ML carrier.

 I must say I disagree relatively strongly with this for several reasons:

0. Extra dependency. I'd like to keep the possibility to use SOCI on
   platforms where this might matter.

1. Basic data model mismatch: we don't need a tree as there is no
   hierarchal structure in play here.

2. Smells like over-engineering: we don't need to read/write these objects
   to file and we definitely don't need XML nor JSON (nor even INI) here.


ML Looking forward to discussing options?

 I'd like to propose with the solution based on adding a
soci::backend_options class which would just wrap std::mapstring, string
but might provide a simpler/higher level adapter over it. Then we could use
the simplest possible implementation for now and something more powerful
later if really needed.

 One question which is immediately going to appear: should the backends
complain about the unknown options or silently ignore them for forward
(and perhaps cross-backend) compatibility? What do you think?

 Thanks,
VZ


pgphLgR2mPID8.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists

Re: [soci-users] MySQL Query: select round( -111100237735.42999, 2 )

[Vadim Zeitlin]

On Sun, 3 Feb 2013 14:17:49 -0800 Pawel Aleksander Fedorynski 
pfe...@gmail.com wrote:

PAF It occurs to me that some other db engines (Oracle?) probably send values
PAF in non-string format, what should into_as_raw_text() do then?
PAF 
PAF (a) signal an error?
PAF 
PAF (b) put the raw value (which may be non-printable and may be packed in some
PAF unobvious way) in the provided string, say the value is of type INT32 and
PAF some db sends four bytes over the wire, should we put these exact four
PAF bytes into the string?
PAF
PAF (c) convert to string?

 I'd say (b). Raw would seem to mean this, i.e. exactly the bytes
received. Of course, the documentation should be very clear about this.

 Regards,
VZ


pgpj6EayamGOT.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] [SOCI-users] Is it correct to silently ignore truncations?

[Vadim Zeitlin]

On Sun, 3 Feb 2013 19:28:48 + Mateusz Loskot mate...@loskot.net wrote:

ML I reckon, it could be added in SOCI 4.0.0 or later.
ML Feel free to add it to https://github.com/SOCI/soci/wiki/Roadmap
ML so it's not missed.

 OK, thanks, I've created https://github.com/SOCI/soci/issues/51 and added
a reference to it to that page.
VZ


pgpHKx2XbvaA2.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] MySQL Query: select round( -111100237735.42999, 2 )

[Vadim Zeitlin]

On Sun, 3 Feb 2013 14:31:06 -0800 Pawel Aleksander Fedorynski 
pfe...@gmail.com wrote:

PAF On Sun, Feb 3, 2013 at 2:26 PM, Vadim Zeitlin vz-s...@zeitlins.org wrote:
PAF 
PAF  On Sun, 3 Feb 2013 14:17:49 -0800 Pawel Aleksander Fedorynski 
PAF  pfe...@gmail.com wrote:
PAF 
PAF  PAF It occurs to me that some other db engines (Oracle?) probably send
PAF  values
PAF  PAF in non-string format, what should into_as_raw_text() do then?
PAF  PAF
PAF  PAF (a) signal an error?
PAF  PAF
PAF  PAF (b) put the raw value (which may be non-printable and may be packed
PAF  in some
PAF  PAF unobvious way) in the provided string, say the value is of type 
INT32
PAF  and
PAF  PAF some db sends four bytes over the wire, should we put these exact 
four
PAF  PAF bytes into the string?
PAF  PAF
PAF  PAF (c) convert to string?
PAF 
PAF   I'd say (b). Raw would seem to mean this, i.e. exactly the bytes
PAF  received.
PAF 
PAF Yes, I was thinking the same thing.  But then it shouldn't be raw_text,
PAF raw_string maybe or raw_bytes even?

 Yes, taking this into account, into_raw_bytes() or maybe into_raw_buffer()
(just because buffer is something you can put things into, while
bytes... not so much IMHO) does seem better, thanks!
VZ


pgpWbBaakoeM3.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] What is status of integer types support?

[Vadim Zeitlin]

On Tue, 5 Feb 2013 01:53:27 + Mateusz Loskot mate...@loskot.net wrote:

ML Here are my findings:
ML 
ML 1) Here is old thread unsigned int and SOCI from 2010 in which Maciej
ML explains reasoning behind certain decisions regarding lack of unsigned int
ML mapping:
ML 
ML http://sourceforge.net/mailarchive/message.php?msg_id=24344961
ML 
ML 2) I found some forgotten work made by Julian Taylor:
ML 
ML http://sourceforge.net/mailarchive/message.php?msg_id=26994744

 Interesting, thanks. I have to say that I had no idea about this previous
work (and probably would have avoided touching this code at all if I read
the first thread and knew it was such a controversial area). My changes
were motivated solely by the desire to avoid internal inconsistencies in
SOCI.

ML 3) Latest changes related to integer types support were made by Vadim,
ML here are two important commits:
ML 
ML a) Handle unsigned integer types as their signed versions.
ML 
ML https://github.com/SOCI/soci/commit/2a8840505ba67b4413c6cd9192965d95f1d0805c

 I.e. this commit prevents SOCI from treating unsigned short as unsigned
long long instead of short. Arguably, having separate mapping for
unsigned short and short might be even better but if we have to choose
between the existing types, I hope everybody can agree that mapping it to
unsigned long long doesn't make much sense.

ML b) Remove dt_unsigned_long and x_unsigned_long type constants.
ML There is no need for a separate type for unsigned long as we don't have
ML special types neither for unsigned int nor for long ...
ML 
ML https://github.com/SOCI/soci/commit/4f8bc05242e6e5dfc6c4d003049c44ca62890cd9

 This was also just an inconsistency, having dt_unsigned_long but not
dt_unsigned_{short,int} didn't make any sense IMHO.

ML AFAIU, the action in 3) clears all the doubts discussed in 1)

 I don't think so. Ideally support for unsigned types in into() would check
that we're really reading a positive value whereas currently I think it
will happily cast a negative int to unsigned too (but I didn't check it).
So ideally we'd need to perform the checks done in
src/core/unsigned-types.h somewhere...

ML and also moves the work in 2) out of scope of SOCI. Right?

 Again, I'm not sure about this. I think having support for [u]intN_t could
be useful as I did already have problems with sizeof(long) being different
between platforms. OTOH I think support for these types should be added
while preserving support for the normal C short/int/long types instead of
replacing them as Julian Taylor's branch seems to do.


ML I believe, it's important to summarise the current status of integer
ML types support in SOCI, together with a few words of explanation why
ML certain decisions have been made. Such summary should go into docs.

 This would be definitely useful.

ML I'd like to do it, but I realised the current status is unclear to
ML myself too.

 Unfortunately I can't say I understand everything neither :-(

ML A few basic questions I'd like to clarify in the docs:
ML 
ML 1. What C++ integer types are supported (mapped) and usable with into/use?

 I believe the answer is: char, [unsigned] short/int/long/long long.
Somewhat surprisingly, not unsigned char.

ML 2. What C++ integer types are not mapped? Why?

 AFAICS only unsigned char isn't. I don't know why, I think it's just an
omission.

ML 3. When we decide what integer types to map, which side has the higher
ML priority, SQL types or C++ types?
ML IOW, do we aim to cover as many SQL types as possible, then decide
ML how to map them to C++ types; or we aim to map as many C++ types
ML as possible, and then decide how those fit the SQL types?

 I think the goal is to be able to save values of any standard C++ type in
the database and read it back, so from this point of view you could say
that C++ has priority. OTOH, in principle, we could also add custom types
to represent SQL types not available in C++. So I don't see the 2
approaches as contradictory, rather they're complementary.

ML Also, If the C++ types have higher priority, then what about Julian's
ML proposal. Wouldn't it make sense to switch the API to C99-based integer
ML types?

 As I wrote above, I think it would be nice to have support for, say,
uint32_t. But I don't believe it's a good idea to drop support for int or
unsigned int, both should be available and the application programmers
should use the one that is more appropriate. E.g. when writing some new
code from scratch, it would probably make more sense to use intN_t types
explicitly. But when adding database support to some existing code, which
uses many int/long/unsigned variables it would definitely be much more
convenient to work directly with them instead of having to convert them
to/from sized types all the time.

 Regards,
VZ


pgp6vC1luQG18.pgp
Description: PGP signature
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before 

Re: [soci-users] RFD: how to specify whether ODBC backend should prompt the user?

[Vadim Zeitlin]

On Mon, 4 Feb 2013 01:05:39 + Mateusz Loskot mate...@loskot.net wrote:

ML On 3 February 2013 21:39, Vadim Zeitlin vz-s...@zeitlins.org wrote:
...
ML   I'd like to propose with the solution based on adding a
ML  soci::backend_options class which would just wrap std::mapstring, string
ML  but might provide a simpler/higher level adapter over it. Then we could 
use
ML  the simplest possible implementation for now and something more powerful
ML  later if really needed.

 Hello again,

 I've started implementing this today but the more I was looking at it, the
less sure I was becoming about the idea of adding an extra argument to all
the existing session opening functions. I.e. consider that currently we have

class SOCI_DECL session
{
public:
session();
session(backend_factory const  factory, std::string const  
connectString);
session(std::string const  backendName, std::string const  
connectString);
explicit session(std::string const  connectString);

void open(backend_factory const  factory, std::string const  
connectString);
void open(std::string const  backendName, std::string const  
connectString);
void open(std::string const  connectString);
...
};


And now we'd need to tack on an extra connect_options const  options =
connect_options() to the end of each of these methods. They are not very
readable already, and adding another argument really won't help.

 So perhaps I should avoid touching the ctors and add another family of
overloads with connect_options at the end, called, say,
open_with_options()?

 Or do you think I'm overthinking this and adding connect_options to the
existing methods won't do any harm?

 BTW, there is also a rather wild idea of replacing the existing
connectString argument with some connectionDescription one combining
both the string and the options. For backwards compatibility we'd have an
implicit connect_desc ctor from std::string but we could also add methods
such set_option(name, value) on this object. This seems a bit too smart
for its own good but OTOH this kind of makes sense and would allow us to
avoid having to introduce open_with_options() while also avoiding
increasing the number of arguments to the existing overloaded functions.

 What do you think, do you have any preferences here or maybe some other,
better ideas?

 TIA,
VZ


pgpI7Tf7JAJmG.pgp
Description: PGP signature
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Firebird tested on Linux

[Vadim Zeitlin]

On Mon, 18 Feb 2013 13:53:27 + Mateusz Loskot mate...@loskot.net wrote:

ML It should work automatically.

 I didn't realize it was as smart as this, sorry, I should have just waited
a bit instead of asking.

ML See the screenshot attached, this build failed as meanwhile
ML I'd broken the common-tests.h, sorry, fix followed

 Sorry for more newbie questions but how do I retry the test now?

 BTW, while we're on the testing topic, would you have any idea how to
configure the Firebird test to work with the official Debian (I think it
should be the same thing under Ubuntu) packages? I can't make it work on my
system because there doesn't seem to be any way to install libfbembed.so as
libfbclient.so, and as soci_firebird_test depends on the latter and not on
the former, the only way to make it work I can see is to copy
/usr/lib/libedit.so.2 to ~/tmp/libfbclient.so and put ~/tmp as the first
directory of LD_LIBRARY_PATH when running the test. But surely there must
be some other, better way?

 Thanks again,
VZ


pgpkXeYC5St0D.pgp
Description: PGP signature
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] RFD: how to specify whether ODBC backend should prompt the user?

[Vadim Zeitlin]

On Mon, 11 Feb 2013 13:13:44 + Mateusz Loskot mate...@loskot.net wrote:

ML Yet another proposal open for comments:
ML 
ML What about using the little Encapsulated Context pattern?
...
ML Implementation options:
ML 
ML 1) Keep current soci::session interface for backward compatibility,
ML add new ctor and open() taking the context - less intrusive, good for SOCI 
3.2.0
ML 
ML 2) Replace current ctor/open() with single new ones taking only the
ML context object,
ML this could be practical for SOCI 4.0.0 which may no longer be
ML compatible with SOCI 3.x.
ML 
ML The context/environment could have implicit ctor taking
ML (backend_factory, connection_string)
ML so old way of calling is also available.

 Hello again,

 Better late than never: I've finally implemented the above (option (1)),
see https://github.com/SOCI/soci/pull/98

 I couldn't test DB2 backend compilation (where can I get the required
headers/libraries?) but I'm relatively confident that it should continue to
compile and work as the changes are pretty minimal. The other backends seem
to work, see https://travis-ci.org/SOCI/soci/builds/5345893

 Any comments welcome, as usual. TIA!
VZ


pgp5uCgzzlJO3.pgp
Description: PGP signature
--
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
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[soci-users] 2 important Firebird fixes before 3.2.0

[Vadim Zeitlin]

 Hello,

 I'll try to do this properly, i.e. add the unit tests exposing the bugs
these commits fix, but this will take me some time and might not happen
before the next week so for now I'd like to ask to either delay SOCI 3.2 a
little bit or commit (or let me commit) the changes below without the
tests as without them current Firebird is simply unusable for us and
anybody else either re-using the same statement more than once or reading
any floating point numbers from the database.

 Thanks,
VZ

From 8072cd75d757a35c91c81f14a997cad54a96c86f Mon Sep 17 00:00:00 2001
From: Vadim Zeitlin vz-s...@zeitlins.org
Date: Fri, 22 Mar 2013 13:30:45 +0100
Subject: [PATCH 1/3] Fix regression with statement re-execution when using
 Firebird backend.

Since the introduction of endOfRowSet_ flag in 4c3cb629, executing the same
statement again stopped working as the flag was never reset after fetching all
the results of the first execution.

Fix this by resetting it in firebird_statement_backend::execute().
---
 src/backends/firebird/statement.cpp |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/src/backends/firebird/statement.cpp 
b/src/backends/firebird/statement.cpp
index 5eea3e5..a882cc8 100644
--- a/src/backends/firebird/statement.cpp
+++ b/src/backends/firebird/statement.cpp
@@ -438,6 +438,10 @@ void firebird_statement_backend::prepare(std::string const 
 query,
 }
 }

+// Successfully re-executing the statement must reset the end of rowset
+// flag, we might be able to fetch data again now.
+endOfRowSet_ = false;
+
 if (sqldap_-sqld)
 {
 // query may return some data
--
1.7.9


From c259bfa3437e75e7446fddb62a2d6300ed59cf12 Mon Sep 17 00:00:00 2001
From: Vadim Zeitlin vz-s...@zeitlins.org
Date: Fri, 22 Mar 2013 13:46:19 +0100
Subject: [PATCH 2/3] Fix reading negative doubles from the database with
 Firebird backend.

Mantissa of type SQL_LONG must be converted to int, not unsigned, when
reading from the database.

This corrects the changes of 4c3cb629 which did use int in other places where
SQL_LONG is handled but not here for some reason.
---
 src/backends/firebird/common.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/backends/firebird/common.h b/src/backends/firebird/common.h
index f4c90a4..f0f48ce 100644
--- a/src/backends/firebird/common.h
+++ b/src/backends/firebird/common.h
@@ -201,7 +201,7 @@ T1 from_isc(XSQLVAR * var)
 case SQL_SHORT:
 return static_castT1(*reinterpret_castshort*(var-sqldata)/tens);
 case SQL_LONG:
-return 
static_castT1(*reinterpret_castunsigned*(var-sqldata)/tens);
+return static_castT1(*reinterpret_castint*(var-sqldata)/tens);
 case SQL_INT64:
 return static_castT1(*reinterpret_castlong 
long*(var-sqldata)/tens);
 case SQL_FLOAT:
--
1.7.9


pgpo__4uzF9do.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] 2 important Firebird fixes before 3.2.0

[Vadim Zeitlin]

On Fri, 22 Mar 2013 14:40:36 + Mateusz Loskot mate...@loskot.net wrote:

ML  ML If you say we can release without the tests added, just with the
ML  ML fixes, let's do so.
ML 
ML   The endOfRowSet fix is perfectly safe to apply, it can't break anything
ML  because it changes nothing if execute() is called only once and if it's
ML  called twice or more times, currently it doesn't work at all so anything
ML  else can only be an improvement.
ML 
ML I see.

 This was indeed correct.

ML   The s/unsigned/int/ fix for SQL_LONG is slightly more risky but, still,
ML  right now you simply get completely wrong values when reading from the
ML  database (something like 4953.956 when the database contains -0.0013), so
ML  IMO it would still be better to apply it rather than not do it because
ML  silently reading wrong data is one of the worst things that can happen in
ML  a database library.

 The above was correct too, in the more risky part. It turned out that
this fix did break Firebird tests[1] and that unsigned was used here to
work around the incorrect result when we casted 40 (which is
greater than INT_MAX on 32 bit systems) to int and then to unsigned long
which could be 64 bits, yielding a wrong value.

 However I don't believe the original fix by Viacheslav (see 4c3cb629)
was the right way to do it, it only hid the problem but didn't solve it.
Using SQL_LONG for unsigned long simply can't work on LP64 systems
because SQL_LONG is just not big enough. So the real fix is to use
SQL_INT64 here and this is as simple as creating the column of right type
in the test database and this is what my fix[2] does. And with that fix
applied, the original commit fixing reading doubles still works and doesn't
break the tests any more.

ML Indeed, we should aim to straighten the numeric types support as much
ML as we can, within the extent of what we support now, I mean, without
ML introducing new types yet. So, I'm glad you've got fix for that issue.

 Yes, I'm glad too because at one moment I was ready to totally despair...
But finally it's not too bad and, provided that you use the correct column
types, things do seem to work now.

 Still, the SQL to C++ types mapping is a huge mess and it clearly should
be the main focus of SOCI 4.0 release.

ML  ML Are you OK with releasing your fixes but without tests in 3.2.0?
ML 
ML   I prefer to commit them without tests to not committing them at all but
ML  I'll try to add the tests too. Just please let me know until when do I 
have
ML  to do this.
ML 
ML Let's say Sunday midnight :)

 This means we still have 36 hours for testing, so I'd like to ask
everybody potentially affected by these issues to test the changes at

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

 Please let me know if you see any unexpected results or have any remarks
or questions. TIA!
VZ


[1] Which I finally managed to run with embedded Firebird here, although
only using a dirty hack of creating a link to libfbembed.so called
libfbclient.so and putting it in LD_LIBRARY_PATH, i.e. in front of the
real libfbclient.so. I'd still like to have a proper fix at CMake level
but at least now I can run the tests which is already good.

[2] https://github.com/vadz/soci/commit/700fb7df7ae4dfd5ea04082a239340c49045c116


pgpU51LvTQl60.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[soci-users] Using a unit testing framework?

[Vadim Zeitlin]

 Hello,

 I've done my first modifications to the SOCI unit tests recently and it
wasn't a very pleasant experience. The 2 main reasons for this are the
rather unusual tests organization and the use of assert() instead of some
more advanced mechanism. I'm especially riled by the latter because
assert() is just not good enough: it doesn't show you which test failed, it
doesn't show you the values of the variables with which it failed and it
doesn't allow you to continue running past the first failure.

 So I wonder what do you think about using some testing framework instead.
Considering SOCI existing dependencies on Boost it could make sense to use
Boost.Test (http://www.boost.org/doc/libs/1_53_0/libs/test/doc/html/index.html)
but OTOH all the current dependencies are optional, while this one would be
semi-required as it's really nice to be able to run tests even if you don't
use Boost.

 Hence an alternative solution: CATCH. This means C++ AutomatedTest Cases
in Headers and, as you can see at https://github.com/philsquared/Catch [1]
it is just a single header and all you need to do to start using it is to
just include it. It is also really nice in that it's enough to write

CHECK( ul == 40ul );

to see the value of ul if the test fails, i.e. you have just a single
CHECK() which does everything, whereas with Boost.Test you need to use a
specific macro:

BOOST_CHECK_EQUAL( ul, 40ul );

Personally I think this is a great idea but I admit that I haven't used
CATCH in really big test suites so I don't know what effect all the
meta-programming machinery necessary to make the above work has on the
compile times. Still, I believe CATCH would be a good fit for SOCI, so what
do you think about starting to use it?

 And if not, using Boost.Test would still be much better than relying on
bad old assert()...

 Finally, this is definitely not 3.2-critical but it would be nice to have
an agreement about this before the tests need to be modified the next time.

 Regards,
VZ

[1] If you want to see the project activity, look at integration branch,
not the default master.


pgpyIlnqwGX_A.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] 2 important Firebird fixes before 3.2.0

[Vadim Zeitlin]

On Sun, 24 Mar 2013 00:10:15 +0400 Viacheslav Naydenov vac...@yandex.ru wrote:

VN 23.03.2013, 16:49, Vadim Zeitlin vz-s...@zeitlins.org:
VN  On Fri, 22 Mar 2013 14:40:36 + Mateusz Loskot mate...@loskot.net 
wrote:
VN 
VN  ML   The endOfRowSet fix is perfectly safe to apply, it can't break 
anything
VN  ML  because it changes nothing if execute() is called only once and if 
it's
VN  ML  called twice or more times, currently it doesn't work at all so 
anything
VN  ML  else can only be an improvement.
VN  ML
VN  ML I see.
VN 
VN   This was indeed correct.
VN 
VN Ok, shouldn't it behave the same way for any other backend?

 It should and AFAIK it does but I didn't test all of them and would prefer
to avoid breaking tests just before a release.

VN May be the test-case you've added is better placed in common tests?

 Yes, I do think it should be in common, I'll just wait until the release
is done before doing it there. The same applies to negative doubles tests,
BTW, there is really nothing Firebird-specific in it.


VN Sorry, my bad. In Firebird a column of decimal(9,0) is represented by
VN 32-bit integer type internally, but still it is not suppsed to store
VN 40 correctly. However, fbclient API doesn't give a warning
VN about this, while the console client does.
VN 
VN SQL create table test_types2 ( col1 decimal(9,0) );
VN SQL insert into test_types2(col1) values(40);
VN Statement failed, SQLSTATE = -802
VN arithmetic exception, numeric overflow, or string truncation

 Interesting, I thought isql was just a simple wrapper using the API calls
so I don't understand how does it happen that it works using the API but
not interactively. I really don't know much about Firebird API (and there
doesn't seem to be any good documentation for it, the best I could find was
Interbase manual from Borland) but could we not check for errors properly?


 Anyhow, to get back to my changes: do you see anything wrong with them or
any objections to committing them?

 Thanks,
VZ


pgpkluCsnAj90.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Using a unit testing framework?

[Vadim Zeitlin]

On Sat, 23 Mar 2013 15:54:54 +0100 Denis Arnaud denis.arnaud_s...@m4x.org 
wrote:

DA Hi Vadim,
DA 
DA Boost.Test, in combination with CMake, works pretty well.

 Hello Denis,

 I have no doubt that Boost.Test works well, I used it in several projects
(CMake -- not so much, but it's a different story) and until recently it
was my preferred C++ unit testing framework. But then I discovered CATCH
and was really impressed by it, although, again, I didn't use it enough to
be sure that it scales well, and I also think it's a nice match for SOCI as
it doesn't need to be built and is also more lightweight/even less
restrictive than Boost.Test and so it should be easier to transition to it.
Also, it is still actively developed and improved, unlike Boost.Test which
hasn't changed for years. So I think it could be interesting to try using
CATCH. After all, why not?

DA You can browse through a full example with the following project:
DA http://github.com/airsim/stdair/. By default, (Boost.Test-based) test
DA checking is activated; it may be de-activated thanks to the
DA '-DENABLE_TEST:BOOL=OFF' option passed to the CMake command-line.

 Thanks, this should definitely be useful if we go this way. But personally
I'd still be curious to try using CATCH.

 Regards,
VZ


pgpYVfEyxhXvx.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Using a unit testing framework?

[Vadim Zeitlin]

On Sun, 24 Mar 2013 01:13:10 -0300 Ricardo Fabiano de Andrade 
ricardofabianodeandr...@gmail.com wrote:

RFdA Currently, I'm working with googletest. It's suprisingly simple to
RFdA get used to and extremely produtive.

 What are the advantages of Google Test compared to Boost.Test? I know that
you mentioned testing template classes but I've never had any problems with
this when using Boost.Test so I'm not sure what is this about exactly. And
when in doubt, I'd rather choose a Boost library over a Google one for
several reasons.

RFdA BTW, soci has been mentioned in the papers/proposals of the next C++
RFdA standard (see N3612).

 I didn't see this one yet, thanks! Here is the link for the lazy:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3612.pdf

RFdA Finally, the idea behind CATCH (a single header) is awesome but in my
RFdA opinion the framework is too immature right now.

 As I said, I don't have much experience of using it in real projects yet
so it could definitely be the case, but could you please explain what
exactly do you mean, i.e. how does its immaturity manifest itself?

 Thanks,
VZ


pgpcQ05hLvVB1.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Using a unit testing framework?

[Vadim Zeitlin]

On Mon, 25 Mar 2013 11:22:39 + (GMT) Bruce Adams tortoise...@yahoo.co.uk 
wrote:

BA I would highly recommend cppunit as a unit test framework (based on the
BA xunit framework).

 I have very strong feelings about cppunit and would love dearly to use
anything else but it. The best thing I can say about it is that it's better
than using plain assert() but that's all. I could go into the details if it
could be useful but the TL;DR version is that cppunit slavishly copies
xUnit approach which is perhaps good for Java but in C++ there are much,
much better -- and less verbose -- ways to do the same thing.

BA I should imagine the requirements for the boost testing framework are a
BA little different from those of normal libraries as they do more
BA template meta-programming than most normal human beings care for.

 You absolutely don't need to do any template meta-programming when using
Boost.Test. FWIW it doesn't contain much of it internally neither (unlike
CATCH) but as a user you really don't care about it. I'm genuinely curious:
did you use Boost.Test before standardizing on cppunit? Because if you did,
this would make you the first person I've ever heard about who preferred
cppunit to Boost.Test after trying them both...

 Regards,
VZ


pgpQ3iqC56btv.pgp
Description: PGP signature
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] SOCI 3.2.0 released

[Vadim Zeitlin]

On Tue, 26 Mar 2013 02:57:32 + Mateusz Loskot mate...@loskot.net wrote:

ML On behalf of the whole SOCI team I extremely pleased to
ML announce this new release of SOCI 3.2.0 version.

 Congratulations for making this release (and more or less on time, too ;-)
and, more generally, thanks a lot for all the time and efforts you've put
into it recently! It's really great to be able to submit patches and get
reviews for them and, especially, be certain that they will be integrated
and released because there is a motivated and active maintainer.

 Thanks again!
VZ


pgpI3IJvc6YR3.pgp
Description: PGP signature
--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] The next three big things

[Vadim Zeitlin]

On Thu, 28 Mar 2013 15:18:30 + Mateusz Loskot mate...@loskot.net wrote:

ML There has been interesting discussions about integer support
ML and new tests lately and I'll follow up in relevant threads in details soon.
ML There is also lots of ideas and brainstorming about future plans:
ML 
ML https://github.com/SOCI/soci/wiki/Roadmap

 BTW, something is broken on this page with Complete support for C++
integer types not appearing under its own bullet point. I didn't fix this
myself because I thought that you could be still editing this page...

[update: I started writing this in the afternoon but got preempted by other
 things, so you are probably not editing it any more by now, when I
 finally send it]

ML There are three big things that will either require substantial
ML amount of work or will introduce major changes:
ML 
ML 1. Buried headers - major structural change

 I don't think it's as major as this. The only question is whether we want
to provide backwards compatibility or not. Personally I think that it's not
really difficult to do it so why not.

ML 2. New tests
ML 
ML 3. C++ integer types support
ML 
ML Do we all agree to release those features in SOCI 4?

 This is the major stuff, yes. I'd also like to implement #51, already
mentioned in the roadmap, and work on tracing/error reporting. I didn't
have time to really think about it yet, so I'm not even sure if it's going
to be one thing or two but, in brief, I'd like to be able to:

(a) Optionally log all SQL statements being sent to the database.
(b) Be able to show not only the text of failing request but also the
values of parameters used for it.

The last one is especially important as currently our application can give
error messages of the form

Violation of PRIMARY or UNIQUE KEY constraint unique_foo_bar
on table table_name while executing
insert into table_name(foo, bar) values (:foo, :bar)

which is singularly unhelpful -- we really need to have the values this
statement was executed with and not just the placeholders.


ML Initially, having SVN experiences in mind, I thought it's
ML important to do the buried headers and all structural
ML changes first.
ML Is my concern justified, shall we do the revolution first?

 Even if Git is capable of dealing with renamed/moved files, it's still
probably better to do this relatively quickly/atomically because even if
you can resolve conflicts resulting from moving a modified file, it doesn't
mean you want to or are are going to like doing it.

ML The branches will be most likely long-running branches,
ML so I'd like to publish them in SOCI/soci repo,
ML i.e.
ML feature/buried-headers

 I'm really not sure why should this one be long-running... Am I missing
some extra difficulty here?

 Thanks,
VZ


pgpH2ZOB7qF6g.pgp
Description: PGP signature
--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Using a unit testing framework?

[Vadim Zeitlin]

On Sun, 7 Apr 2013 04:52:48 +0100 Mateusz Loskot mate...@loskot.net wrote:

ML Here are some of my more important points:
ML 
ML Using gtest + gmock will effectively add two new
ML dependencies to SOCI. Same for CATCH + Turtle (or other mocker).
ML Using Boost.Test + Turtle (Boost.Mock) will add, let's say, one (Turtle)
ML and 'half' (Boost). Currently Boost is optional but I suppose many if not
ML most users build SOCI with Boost, same for packes.
ML If someone has Boost installed, I think it's safe to assume it's complete
ML Boost distribution, so there are Boost.Test headers available
ML (if we are header-only-philic here, we'll be fine :-)).
ML Another important advantages of Turtle is that its interface, style and
ML conventions match Boost's. This promises seamless integration.

 Hello,

 I think the dependency point is pretty important for the testing
framework. Of course, for any developer of the library it's not difficult
to install either one of the libraries mentioned above (or all of them :-)
but this is not the only case where the dependencies matter. I'm thinking
more about the users who may be asked to run the SOCI tests, perhaps with
some small changes, to help debugging some problem. And also about
occasional contributors who'd have much higher probability of updating the
tests if they didn't need to install anything extra to be able to run them.

 From this point of view, CATCH is perfect IMHO because it's just a single
header, that could (and should) be included in SOCI sources themselves.
Boost.Test can be used in header-only mode but this is not its preferred
mode of operation and it's not explained very clearly in the documentation
(AFAIR...) but it's still acceptable. Asking people to compile googletest
themselves is much less so.
 
ML Neither CATCH nor Turtle seems to be packaged,

 Again, CATCH is not packaged because it doesn't need packaging, this is
the appealing part.

ML There are solid communities behind Google and Boost, seems promising.

 It was news to me that Boost.Test was still developed, to be honest I was
pretty sure it was abandoned after seeing no changes to it since many
years. It's definitely good to know that Gennadiy is still working on it.
It's less good to know that he still doesn't have time (nor any real plans,
apparently) to update the documentation. More generally, reading the What
should we do thread on Boost mailing list didn't inspire me with much
optimism, there seems to be a real disconnect between the users of this
library and its author. Of course, I only skimmed the messages, so maybe my
impression was wrong.

 Also, I have to say that I don't care that much about future prospects of
the testing framework because it must already provide everything we need
right now and it must be stable, you definitely don't want your testing
foundations shifting under your feet. And Boost.Test is definitely stable.
Although some hints of planned incompatible changes (let alone the menace
of deprecating it and removing it from Boost entirely) in the thread above
are not really confidence-inspiring neither.

ML I'm not sure about status of CATCH. I know its author Phil from ACCU.org
ML and remember there has been load of discussions at the time this library
ML was forming, but recently it seems slowed down, still not released (?).

 This is clearly the main problem with CATCH -- it's too new. We don't
really know anything about its track record and can't really be sure about
its future development. But, again, if it satisfies us right now, in its
current form, does it really matter?


 Anyhow, to summarize, for me there is the default choice which is
Boost.Test and an intriguing new challenger which is CATCH. I don't
consider googletest at all because it's an extra (compiled) dependency and
because, after using/looking at several Google C++ libraries, I just don't
like them that much, the code quality is IMNSHO much higher in Boost than
in Google C++ code.

 The main advantages of CATCH are the ease of installation (none needed)
and the automatic generation of assertion failure messages which is IMO
very nice. But it could have drawbacks that I'm not aware of just because I
didn't use it enough, while with Boost.Test we can be pretty sure to not
have any unpleasant surprises. But the status of Boost.Test as a de facto
standard unit testing library for C++ is quite a bit more doubtful to me
now that I read that thread on boost mailing list. To be honest, I could
never imagine that its removal from Boost would be seriously considered and
even if it doesn't, as I hope, happen, it's still worrisome.


ML Unless a solid reason appears that will back up one option, I think the
ML choice will be made driven by self-regulated natural forces of
ML community (tm) :-), that is at some point someone will start rewriting
ML tests, will make no-brainer decision choosing her/his preferred testing
ML framework and complete certain substantial amount of work in this area.

 I 

Re: [soci-users] Using a unit testing framework?

[Vadim Zeitlin]

On Mon, 8 Apr 2013 16:56:20 +0100 Mateusz Loskot mate...@loskot.net wrote:

ML  ML Neither CATCH nor Turtle seems to be packaged,
ML 
ML   Again, CATCH is not packaged because it doesn't need packaging, this is
ML  the appealing part.
ML 
ML I meant packages deploying, like its common to have Boost headers packaged.

 I see, sorry for the misunderstanding. I didn't realize you were already
using the same approach with TUT (which, BTW, I didn't spend much time on
just because the example on http://tut-framework.sourceforge.net/ is pretty
weird-looking, at least compared to the one at
https://github.com/philsquared/Catch/wiki/Tutorial), so I just wanted to
emphasize this, IMHO important, aspect.


ML BTW, I know Phil is going to give talks about CATCH during a few upcoming
ML conferences in UK, so that is a good indicator the project is active.

 Also, knowing how these things happen, he'll probably have a few things
to fix/improve in CATCH too after these talks...

ML Fair point. CATCH does not completely fit my preferred coding styles,
ML but I'll be open minded :-)

 Well, the combined header (catch.hpp) is definitely pretty horrible, but
browsing the code in their repository doesn't immediately show anything too
bad. The worst thing I noticed, style-wise, was the use of identifiers
starting with underscores, which should clearly be avoided but OTOH is not
quite a firing offense neither.

ML   The main advantages of CATCH are the ease of installation (none needed)
ML 
ML If we consider CATCH, I assume we will simply host copy of its headers
ML inside SOCI, right?

 Yes, I think we should put catch.hpp somewhere in our sources.

ML  ML Why I mention mock every time?
ML 
ML   Good question :-) I'm really not sure if we need it at all, what are we
ML  going to mock exactly?
ML 
ML Core. I am very keen in exercising mocking techniques against the core.

 I must admit that I don't follow you at all here. For me mocking is used
to replace a component that can't be easily tested (e.g. because it uses an
external data source which is not always available) with a mock-up that
emulates this component in a predictable way and can also be used to verify
that it's used as intended. So if we mock the core itself, what are we
testing then?

ML  A database backend?
ML 
ML Nope, backends rely onDBMS specific features, so testing them in isolation 
from
ML related DBMS is pointless.

 My idea was to use mocking to check that the core code calls the
appropriate backend methods, as expected. I'm not sure if this really has
an enormous value but I at least can understand this, unlike the idea of
mocking the core which still has me scratching my head...


ML So, to summarise my position, I'd be in favour to start rewriting
ML tests using CATCH.
ML Once we start, we should soon be able to confirm if it is lacking any
ML features or not.

 This would be perfect from my point of view. And the mocking discussion
can probably wait until later.

 Thank you for driving this process!
VZ


pgphjmYj7E1DP.pgp
Description: PGP signature
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Slides from SOCI talk at London C++ Meeting

[Vadim Zeitlin]

On Tue, 28 May 2013 23:38:47 +0100 Mateusz Loskot mate...@loskot.net wrote:

ML I've just came back form the first London C++ Meeting
ML at Google Campus [1] where I had pleasure to give introductory
ML talk about SOCI, on basic idea behind the library and
ML core concepts the library heavily relies on.
ML 
ML Here are the talk slides:
ML 
ML http://slid.es/mloskot/soci

 Hi Mateusz,

 Congratulations for the nice presentations, thanks for making the slides
available and sorry for not finally being able to come to London to meet
you, unfortunately I just had too much of other work recently to be able to
do it. When is the next meeting? ;-)

ML I guess, it may serve as not-a-bad overview for anyone
ML new to SOCI, before diving into the SOCI source
ML code and documentation.

 People love slides, usually (not as much as graphs, but as it's going to
be a bit difficult to produce those for SOCI, we'll have to do with what we
have ;-), so I'd definitely add a link to them to SOCI home page.

ML I may update the slides in future or derive new talks.
ML Feel free to use it yourself if you like.

 Not that I have any plans to reuse them, but I just wonder: how can people
actually do it? I.e. what are the sources of the slides and can they be
obtained from slid.es somehow?

 Anyhow, once again, this is a very nice short introduction to SOCI,
thanks!
VZ


pgpAfZSBqYDjN.pgp
Description: PGP signature
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Ways to deal with many columns

[Vadim Zeitlin]

On Sat, 22 Jun 2013 15:49:07 -0600 Jordan Woehr jordanwo...@gmail.com wrote:

JW However, for inserting I'm having difficulty. What I want to achieve is
JW something as follows:
JW 
JW int vals[NUM_VALS];
JW statement st = s.prepare  INSERT INTO table (c0, c1, c2, ...) VALUES (;
JW for(int i = 0; i  NUM_VALS; ++i)
JW st  vals[i];
JW st  );
JW st.execute();
JW 
JW Is anything like this possible?

 Why not? You just need to postpone the statement construction until after
you build the full SQL script in this loop. And you can call
statement::use() in the loop too.

 Regards,
VZ


pgpm31Ni0AKG3.pgp
Description: PGP signature
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Support of MSSQL Server

[Vadim Zeitlin]

On Sun, 23 Jun 2013 13:03:32 +0200 (CEST) heiko.r...@code-styling.de 
heiko.r...@code-styling.de wrote:

hs My plan is to clone the ODBC backend and come up with a first version
hs of a new MSSQL interface.

 Hello,

 Having a native MS SQL backend would be very nice to have in any case,
even independently of the Unicode issues, so it would be definitely great
to at least start working on this.

hs But there is a global issue doing so. I need the extends the core with
hs support of
hs 
hs #define SQL_WCHAR (-8)
hs #define SQL_WVARCHAR (-9)
hs 
hs with a new core data_type
hs 
hs   dt_wstring
hs 
hs and exchanged to
hs 
hs  std::wstring.

 This would be already useful and AFAICS shouldn't be a big problem to
implement but I think it would be really useful to also allow exchange
between Unicode database fields and UTF-8-encoded std::string (no w).
What do you think?

hs Should the support additionally enrolled to any other backend too if
hs the backend is able to support such types using std::wstring?

 Ideally all this should be backend-independent, of course. Even if the
backend doesn't specifically support Unicode at all, we could just encode
std::wstring in UTF-8 and use the existing code. In fact, I'd think that
this would be the right thing to do for all the other backends but I didn't
actually check it.

 Regards,
VZ


pgpAWGd_pzPFX.pgp
Description: PGP signature
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Support of MSSQL Server

[Vadim Zeitlin]

On Mon, 24 Jun 2013 16:47:32 +0100 Mateusz Loskot mate...@loskot.net wrote:

ML  hs But there is a global issue doing so. I need the extends the core with
ML  hs support of
ML  hs
ML  hs #define SQL_WCHAR (-8)
ML  hs #define SQL_WVARCHAR (-9)
ML  hs
ML  hs with a new core data_type
ML  hs
ML  hs   dt_wstring
ML  hs
ML  hs and exchanged to
ML  hs
ML  hs  std::wstring.
ML 
ML   This would be already useful and AFAICS shouldn't be a big problem to
ML  implement but I think it would be really useful to also allow exchange
ML  between Unicode database fields and UTF-8-encoded std::string (no w).
ML  What do you think?
ML 
ML UTF-8 is Unicode, but I guess it's a shortcut.

 Yes, sorry, I used Unicode in Windows sense of the word where it
typically means wchar_t (i.e. UTF-16).

ML Do you mean a field of UTF-8 and select into(std::wstring)
ML or field of UTF-16 and insert with use(std::string) ?

 Both. I.e. IMO ideally any text database fields, be they UTF-8-encoded,
UTF-16-encoded or whatever else[*], should be exchangeable with both
std::string and std::wstring.

ML In fact, currently, we somewhat implicitly assume all std::sting are UTF-8.

 I think it's a perfectly reasonable assumption to make nowadays. It just
needs to be explicit IMO.

ML In limited scenario, we can assume only MSSQL/ODBC on Windows
ML exchange UTF-16 and all the rest exchange UTF-8, then we know
ML statically what conversion to apply.
ML 
ML The problem is if we want to support conversions like:
ML anything -UTF-8
ML anything -UTF-16
ML 
ML Then we have to take care of checking what lingo database/client/backend
ML speak per session.  Don't we?

 If we want to support arbitrary encodings, then we definitely need to do
this, but I don't think we need to do this right now. I'd like to determine
the kind of text based solely on the column type. E.g. for MS SQL we have
NCHAR/NVARCHAR/NTEXT which are always UTF-16 (AFAIK) and CHAR/VARCHAR/TEXT
which always some multibyte encoding. Again, I think this is actually the
only one requiring special treatment, the others all use UTF-8 or another
multibyte encoding -- which we don't support right now.

 Of course, it would be ideal to support all the different encodings too.
But, again, I don't think anybody needs this right now and doing this would
be much more complicated as it would require querying the database
charset/encoding in each session and doing the conversions (which would in
turn probably require linking with ICU).

 So my suggestion would be:

1. Handle only UTF-8 for multibyte encodings right now and, perhaps, throw
   an error if we can detect that the database uses anything else.
   Formalize this by documenting that std::string used by SOCI is supposed
   to always be in UTF-8.

2. Add UTF-16 support for MS SQL and ODBC backends by converting data
   to/from UTF-8.

3. Add support for exchanging data with std::wstring. Do it directly for
   MS SQL/ODBC or via UTF-8 for all the others.

 And the point I was trying to make in my original reply was that IMHO it's
the step (2) that is the most interesting, not so much the step (3) (even
if it would be useful to have it too, but I think any C++ programmer
already uses some library allowing him to easily convert between
UTF-8-encoded std::string and std::wstring anyhow).

 Regards,
VZ


pgpW1IneO3Akh.pgp
Description: PGP signature
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] How to get the final query string

[Vadim Zeitlin]

On Fri, 8 Nov 2013 18:12:13 +0100 JP jp.garcia.or...@gmail.com wrote:

J is there any way to get the final query string that is used by the backend?
J The available methods like get_last_query and get_query_strem return
J the query string as specified to the session, without replacing the items
J like :name with the current value specified using soci::use(name). This
J functionality would be very interesting for debugging, at least in my
J case...

 In mine (and I suspect that of quite a few others) too. Unfortunately
there is no way to do it now, but there is a pull request for it at

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

I still hope to get to it one day and refactor it to work at common code
level instead of being done for each backend individually, but haven't had
time to do it since more than half a year, so I really don't know when is
this going to happen. If you're interested in looking at this, please do!

 Regards,
VZ


pgpV0Tgl3DELT.pgp
Description: PGP signature
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Changing the default branch in the Github repository?

[Vadim Zeitlin]

On Sun, 22 Mar 2015 11:36:23 -0700 Pawel Aleksander Fedorynski 
pfe...@gmail.com wrote:

PAF So from my reading it seems we don't have a clear agreement here?

 Apparently not. I'd just like to point out that since I had started this
thread there was another PR mistakenly done against master instead of
develop (see https://github.com/SOCI/soci/pull/296). Nik, its author, was
kind enough to redo it against develop, so it wasn't a problem but it's
still extra unnecessary friction for would be contributors to the project.

PAF I'd really prefer to defer this decision to Mateusz.

 This is not a problem for this particular decision but I'm not sure if
Mateusz has time for SOCI nowadays (at least I haven't heard from him since
quite some time) and so you might need to take other decisions without him.
Notably I'd like to do SOCI 4.0 release in some observable future (although
I still want to get a few things into it, so observable doesn't
necessarily mean very close...).

 Regards,
VZ


pgpDWr3_zOXZb.pgp
Description: PGP signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Changing the default branch in the Github repository?

[Vadim Zeitlin]

On Sun, 15 Mar 2015 20:31:12 -0700 Pawel Aleksander Fedorynski 
pfe...@gmail.com wrote:

PAF I don't really understand the implications of what you're asking for,

 Sorry, let me try to explain it better: when somebody creates a pull
request for SOCI repository, currently it defaults to the master branch.
This is wrong as all the changes are supposed to be done in the develop
branch instead. Fixing this is not difficult (you just need to select the
develop branch from the branch selection combobox), but annoying even if
you remember to do it and, of course, some people might not know that you
have to do it in the first place.

PAF but if Mateusz doesn't respond within a couple days or say a week,
PAF I'll be happy to do it, especially if you give me instructions how.

 I've actually never done it myself as all my other repositories just use
master branch as the work one and don't use git flow, but AFAICS you just
need to click on the Settings (screwdriver and wrench icon) and change
the Default branch there.

 FWIW this is not a drastic change, it will only affect future PRs and it
can always be undone, so I don't think Mateusz could have any objections to
it...

 TIA,
VZ


pgpNp7kDMDRqe.pgp
Description: PGP signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Changing the default branch in the Github repository?

[Vadim Zeitlin]

On Tue, 17 Mar 2015 10:11:26 +0100 Sebastian Lauwers 
sebastian.lauw...@gmail.com wrote:

SL I'd like to recommend /against/ this. There are two major implications:
SL 
SL - All PRs will default against `develop`, which is what you're asking,
SL - Upon cloning, the checked-out branch will be `develop`.

 Hmm, I hadn't realized this, thanks for mentioning it.

SL There are a number of reasons why I'd recommend against this:
SL 
SL - This can break a number of tools that automagically pull against the
SL repository;

 I'd expect all such tools to fetch all branches but it's not, of course,
impossible, that some of them are broken...

SL - Most users who just want the source code don't necessarily need to
SL know what the development workflow is. As soon as you start tracking
SL the `develop` branch, you know that you're going to be using fairly
SL specific user scenarios. I'd wager that there are a lot more SOCI
SL users than developers.

 This is clearly true, although we can probably assume that only the
advanced users get their sources from git.

SL I'm a believer in the idea that the default branch should be a stable
SL one.

 Notice that this is clearly _not_ the case when _not_ using git flow as
then all the development is done on master and stable releases branch off
it. And I do believe that most people have a clear understanding that
getting the latest master means you get the latest, but not necessarily the
most stable, version.

SL I'm sure there's a greasemonkey script somewhere that would allow you
SL to automagically select `develop` rather than `master`.

 This is not the only problem though. Most of the existing PRs (I was
looking over them recently trying to pick all uncontroversial ones and
apply them) were made against master and not develop too. And I don't see
this changing: when you clone a repository, it's natural to do your changes
in master. So, basically, this means that it will continue to be impossible
to merge PRs easily. And this is IMO a bigger problem, SOCI development is
already almost stalled and not applying PRs quickly is not going to help
get it moving faster again.

 In fact, my personal favourite solution would be to keep master the
default branch but drop git flow entirely. It's probably a good workflow
for managing a team of many developers and a project with many releases,
but neither of these criteria applies to SOCI: there are few developers and
even fewer releases. Using the traditional master-and-release-branches
workflow is simpler and would IMHO be quite enough for this project.

 Of course, this wouldn't help with your concerns as master would be
exactly as [un]stable as develop is now. But if this helped SOCI
development it would be still well worth it IMO.

 Regards,
VZ


pgpoTDO4m9vCj.pgp
Description: PGP signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Changing the default branch in the Github repository?

[Vadim Zeitlin]

On Wed, 25 Mar 2015 10:19:27 +0100 Mateusz Loskot mate...@loskot.net wrote:

ML Having master checked out, I'm ready to submit patches back straight away.

 Sure, you can submit them -- but currently, i.e. when using git flow with
Github, they can't be merged easily (i.e. using the single button in the
web interface). This is exactly the problem which triggered this thread.

ML  SL I'm a believer in the idea that the default branch should be a
ML  stable SL one.
ML 
ML   Notice that this is clearly not the case when not using git flow as
ML  then all the development is done on master and stable releases branch off
ML  it. And I do believe that most people have a clear understanding that
ML  getting the latest master means you get the latest, but not necessarily 
the
ML  most stable, version.
ML 
ML Yes, it seems to be like that, in default GitHub arrangements.
ML GitFlow overrides the role of master and if we do GitFlow, we do
ML master == stable.

 It's even more rigid than this, it's so stable that it practically never
changes -- it's only updated when a release happens. Again, this is not
necessarily bad, but is definitely unusual, people expect to be able to
track changes as they happen if they pull from master, but with git flow
absolutely nothing happens in master.

ML My experience with maintaining and releasing SOCI bugfix releases
ML revealed that one PITAs is
ML 1. Collecting all PRs that qualify for a bugfix release
ML - often fixes submitted in big PR bundles need to be cherry picked
ML - often fixes submitted against develop need to be ported to master
ML - often fixes do not receive any feedback or review, so unclear they are 
good
ML - maintenance is no fun, but a time consuming boring task :)

 No workflow is going to help with the first and the last two points, of
course, but at least the second one is a pure annoyance due to an impedance
mismatch between git flow and Github and we could get rid of it.

ML I chose GitFlow because it is well structured workflow that makes it
ML no-brainer yet simple to follow, with one caveat...once you learn it :)

 Yes, I agree that it's not that difficult. But it's still more difficult
than alternatives. And, while it doesn't excuse my erroneous commits to
master, it's hard to keep track of different workflows when switching
between different projects, so simpler is always better.

 Most of all, I'd like to repeat that it seems obvious that git flow
strength is its good support for multiple active releasable branches and
frequent releases, neither of which is really needed for SOCI.


ML   Of course, this wouldn't help with your concerns as master would be
ML  exactly as [un]stable as develop is now. But if this helped SOCI
ML  development it would be still well worth it IMO.
ML 
ML Ok, let's make it happen, unless there are objections from other
ML developers and contributors.
ML 
ML To make it clearer what we are going to decide between, quick summary:
ML 1. On one hand, we have GitFlow -
ML http://nvie.com/posts/a-successful-git-branching-model/
ML a well structured workflow that proved to be not as well known as I'd
ML assumed and too detailed for SOCI.

 This is the workflow I'd use if I had to make many releases.

ML 2. On the other hand, we have, so called, GitHub flow -
ML http://scottchacon.com/2011/08/31/github-flow.html
ML a kind of rolling release workflow, where master is always deployable
ML aka stable (as in GitFlow)

 This is the workflow I'd use if I didn't have to make any releases.

ML 3. Somewhere in between, we have traditional workflow known from, for
ML example, Subversion:
ML - master - here all development happens (submitted and merged from
ML topic branches!)
ML - release/X.Y.Z - maintenance branch
ML - tags/X.Y.Z - tag

 This is indeed the most commonly used workflow IME. Notice that it's a
strict superset of (2).

ML It seems, git makes release/X.Y.Z redundant

 The usual strategy is to have release/X.Y branch[es] and then X.Y.Z tags
on them.

ML My vote:
ML 1. Drop GitFlow: +1
ML 2. New workflow: +1 for either 2 or 3

 I don't think we can possibly use (2) because we do need 3.2 and 4.0
branches, at least. I do prefer (3) to (1).

 Regards,
VZ


pgp7TOypOwowa.pgp
Description: PGP signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[soci-users] More detailed exception error messages

[Vadim Zeitlin]

 Hello,

 I'd like to return to the following problem: currently, if an SQL query
fails, you often have no idea why exactly did it fail because you don't
have the values of its parameters. A typical example we have to deal with
is that the process importing some data files into the database stops with
an error like this:

database exception: violation of PRIMARY or UNIQUE KEY constraint
PK_FOO on table FOO while executing insert into foo(a, b, c)
values(:a, :b, :c)

This is singularly unhelpful because what the user really needs to know is
for what values of a, b and c this violation happened as this would
allow to immediately locate the duplicate value(s) in the input. But SOCI
doesn't provide this information and without it finding the problem is very
difficult.


 We've talked about this in the past and there is Ricardo's patch at
https://github.com/SOCI/soci/pull/138 from almost 2 years (!) ago as well
as my own attempt at https://github.com/SOCI/soci/issues/245 from exactly a
year ago. In spite of the date, it's really not a joke, we've been
bikeshedding this for literally years without anything to show for it so
far.

 So I'd finally like to really do something about this problem. Notice that
I'm not speaking about the general purpose logging, this could be nice (or
not: all RDBMSs except, perhaps, SQLite, provide their own logging
facilities, so it's not even that obvious that SOCI needs to do it too),
but is not critical for me and so I just want to solve the problem with
insufficiently detailed error messages described in the beginning of this
message. My proposed solution is at https://github.com/SOCI/soci/pull/302
and, as you can see at https://github.com/SOCI/soci/pull/302/files?w=1 (the
w=1 part is important to hide indentation-only changes in statement.cpp
which just distract from the point), it is really very simple:

1. Add get_name() and dump_value() to use_type_base to allow showing the
   parameter values in the error messages.

2. Allow associating extra context with soci_error, which is then appended
   to the error message specified in its ctor to build the full error
   returned by what().

3. Wrap all interesting statement methods in try/catch which rethrow the
   soci_error generated by the lower level code after recording the
   information about the query and its parameters in it.


 This patch is definitely incomplete, all of the items above could, and
should, be extended, e.g. (1) should be generalized to vector and
object-valued parameters, but I think it's a good start because:

- It already solves a real problem in practice.
- It is simple and doesn't introduce any code duplication.
- It has absolutely no overhead at run-time when no exceptions happen.


 To return to the motivating example, the new error message would now be
(and notice that it won't be necessary to manually append get_last_query()
to it, as we do now):

database exception: violation of PRIMARY or UNIQUE KEY constraint
PK_FOO on table FOO while executing insert into foo(a, b, c)
values(:a, :b, :c) with a=bar, b=123, c=baz.

which is much better.

 So I'd like to merge this a.s.a.p., please let me know if anybody has any
objections to this.

 TIA!
VZ


pgpzh0SOKKJLw.pgp
Description: PGP signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[soci-users] Isn't it legal to execute the same statement multiple times?

[Vadim Zeitlin]

 Hello,

 I'd just like to check if I'm not missing something obvious here: I
thought it was perfectly fine to execute the same statement more than once
with different parameter values, e.g. do something like this:

int f;
statement st = (sql.prepare  insert into t(f) values(:f), use(f));
for (f = 0; f  10; f++)
st.execute(true);

And, in fact, this does work fine in the sense that the expected values are
inserted in the database.

 However currently if any values requiring memory allocation are used, e.g.
strings, but also dates and even long longs in some backends, there are
also plenty of memory leaks, at least in the ODBC backend where I
definitely see them, but also, apparently, in some of the other ones from
examining the code. They happen because the code in
whatever_use_type_backend::pre_use() happily overwrites buf_ with the
new allocation without freeing the old one, and if execute(true) is called
more than once, pre_use() is also called more than once.

 So the first question is whether this is really allowed or is this a
misuse of the SOCI API. I hope it it legal and then the memory leaks need
to be fixed. AFAICS there are 2 ways of doing it: either do as MySQL,
PostgreSQL and SQLite backends do and just call clean_up() in post_use(),
or be a bit smarter and reallocate the buffer if it's already allocated
instead of always allocating the new one. This would, of course, mean
switching to realloc() from new[] currently being used, but could be
noticeably more efficient when a lot of execute() calls are done in a loop.

 What do you think?
VZ


pgp3vMrf8y9LQ.pgp
Description: PGP signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] RFD: Using CATCH for tests

[Vadim Zeitlin]

On Fri, 27 Mar 2015 10:05:32 +0100 Mateusz Loskot mate...@loskot.net wrote:

ML   OK, thanks for your support! I won't be able to finish this today, but
ML  I'll try to do it tomorrow or, if this fails too, early next week. One way
ML  or the other, I really want to get CATCH in.
ML 
ML No problem, sounds good.

 OK, this is done now, see https://github.com/SOCI/soci/pull/298

 I'd like to merge this soon and then also rename/move the tests as the
assert part, which annoyed me even before, just totally won't make any
sense after switching to CATCH.

 My favourite solution would be to just move the tests one level up in the
file system, i.e. get rid of the subdirectory completely. But we could also
keep the hierarchy and just rename it to something else, especially if
somebody has any good proposals for the subdirectory name (catch doesn't
count, because it doesn't really matter what do the tests use for their
checks, the name should rather describe what do they do and not how).

 Thanks,
VZ


pgps4aK5gwVWV.pgp
Description: PGP signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] RFD: Using CATCH for tests

[Vadim Zeitlin]

On Thu, 26 Mar 2015 20:17:27 +0100 Mateusz Loskot mate...@loskot.net wrote:

ML   Assuming there are no objections to using it, I'd like to add catch.hpp
ML  
(https://github.com/philsquared/Catch/blob/master/single_include/catch.hpp)
ML  directly to SOCI repository, e.g. as tests/catch.hpp. I don't think it's
ML  worth the trouble to use a submodule for it, but we could do this too if
ML  people prefer it.
ML 
ML Sure. I'd create a branch in the upstream repo, so we can all test and
ML contribute to the new tests transition.

 As you've noticed, currently there is catch-tests in my fork, but I could
push it to SOCI/soci, of course. The trouble is that it doesn't do what you
prefer...

ML   I am less sure about how to handle the transition from assert() to CATCH.
ML  One possibility would be to just globally replace all asserts with
ML  REQUIRE() macros. This would be suboptimal (if only because some of the
ML  asserts should probably be replaced with CHECK(), to allow the tests to
ML  continue if one of them fails), but should be relatively simple to do.
ML 
ML I believe in single assert per test routine/case...see below.

 Sorry, this is unworkable. Currently, i.e. with catch-tests and Firebird
we have

All tests passed (1851 assertions in 54 test cases)

i.e. an average of more than 34 assertions per test. Multiplying the number
of test cases by 34 is not going to help.

 Of course, the current tests are not well-organized and there is ample
scope for improvement here. And we definitely should be splitting some test
cases in sections using the eponymous macro. But we still won't have a
single assert per test case or even per section. But why should this be a
goal in the first place? I really don't see any good reasons to require
it.


ML My plan was to keep the current tests and start (re)writing with CATCH

 This would be my preference as well, in theory, but looking at the amount
of the existing testing code, I realized it would take an inordinate time
to do it, so it's just not going to happen in practice. Hence I decided to
do what I can to improve things right now instead of hoping that the best
case somehow happens on its own in the future...

ML in new folder: tests/integrate.

 What would be the meaning of integration tests for SOCI? I.e. integration
of what with what would they be testing? I am not sure how can we write
more than just unit tests for a library like it.

ML Finally, along the transition, I had an idea to refactor and clean up
ML the tests slightly to test single thing
ML per routines/cases, as short as possible, with Arrange/Act/Assert
ML principle in mind.
ML Perhaps some modularisation and groupping would be a good idea too.

 Yes, it would be definitely nice to streamline all this. But,
realistically, who is going to do it and when is it going to happen?


ML Having explained my points above, I don't think that find  replace
ML assert with CATCH macro is the way to go.

 OK, as you know I've already done this in meanwhile. I actually didn't
want to start on this, I just wanted to add a new test (for checking the
error messages) using CATCH. But it turned out that I couldn't do it
without switching all the rest to CATCH first because I had to use
TEST_CASE or TEST_CASE_METHOD for all the test functions to run them, so I
started doing this and then was annoyed by seeing CATCH messages about N
tests passing but 0 checks being verified, so I also went ahead and did
replace assert()s with CHECKs.

 So the question now is whether this makes things better or worse. IMHO it
does improve them, as the commit message says, using CATCH:

- Provides information about the failed test and the values of variables in it.
- Allows to continue running the tests even if one of them fails.
- Allows to run just some of the tests with flexible selection mechanism.

and all this is pretty convenient already. Additionally, it allows to write
new tests using CATCH and organizing them better, which was the original
impetus for this change.

 It took me a couple of hours to make the changes so far and I'll probably
need at least as much to update the other backends (so far I've only done
it for Firebird), so I'd rather not do it if we don't want to replace
asserts with CATCH CHECK()s. But IMHO it would be a waste, the benefits
above are real and can be had today without any drawbacks (AFAICS).

 The possibilities I see are:

1. Throw away catch-tests branch and start adding new tests using CATCH
   in tests/unit.
  + This would allow cleaner tests, eventually.
  - This still needs more work, notably at CMake level (which I try to
avoid as much as possible personally).
  - We will be stuck with inconvenient to use/debug assert tests for
the observable future.
  - It will also be confusing to have two parallel tests, we'd have to
explain people submitting PRs that they need to update this one and
not the other one, probably more than once.

2. Complete the work done for Firebird on 

[soci-users] CMake and Windows builds

[Vadim Zeitlin]

 Hi,

 Speaking of CMake, how exactly is it supposed to be used under Windows?
I've never used it there with SOCI as we have our own project/solution
files there, but I thought I could just do cmake and then build the
generated solution and apparently this doesn't work because the link
dependencies are not specified correctly, see

https://ci.appveyor.com/project/VadimZeitlin/soci/build/4.0.0.3/job/eh43w5l1v2ip832a

 Any ideas?
VZ


pgph5ssDZiN2H.pgp
Description: PGP signature
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] CMake and Windows builds

[Vadim Zeitlin]

On Tue, 14 Apr 2015 19:54:08 +0200 Mateusz Loskot mate...@loskot.net wrote:

ML It should be easy really. The hardest part is to collect the dependencies.

 MySQL ones seem to be installed and found, yet linking doesn't work...

ML It's been long time since I've done any personal projects on Windows+Visual
ML Studio, a bit neglected that area in SOCI.

 I use SOCI mostly in this configuration, so the code definitely works (and
is tested), it's just the CMake build system which seems to have problems.

ML Apparently something has broke there and I'll have to look at it.
ML I'll work on it this week.

 TIA!
VZ


pgpu0e_wSqFSL.pgp
Description: PGP signature
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Behavior when signed numeric type is to small with soci::into

[Vadim Zeitlin]

On Tue, 18 Aug 2015 11:27:47 + Klemm, Markus markus.kl...@cicor.com 
wrote:

KM What will soci do when I have for example an signed int with a width of
KM 32 bit and binds it to the output via soci::into, to a query, which
KM yields a high signed value. I assume I will get a soci_error or the
KM soci::indicator is set to i_truncated if the value is  2^32-1, but
KM will this happen also if the value is 2^31-1  x  2^32-1 or will I get
KM a overflow?

 To be honest, I don't know what happens in this case and I'm not even sure
if the behaviour is the same across all backends. It would be nice to add a
unit test checking for it and then ensuring that they all do behave in the
same way.

 Regards,
VZ


pgp2xt_74o4qE.pgp
Description: PGP signature
--
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Firebird 3.0

[Vadim Zeitlin]

On Sat, 7 Dec 2019 15:42:39 -0500 Gavin M2301  wrote:

GM> Anyone using firebird 3 with soci?

 Yes, we do, without any problems so far.
VZ

pgplwQPdTl55V.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] ODBC Backend vector use std::string

[Vadim Zeitlin]

On Fri, 7 Feb 2020 20:47:56 + Andrew Grafham  
wrote:

AG> Should it be possible to do the following but with std::string instead of
AG> int? (Example taken from here -
AG> http://soci.sourceforge.net/doc/release/3.2/statements.html )

 I'm not completely sure, to be honest, but I think that ideally it should
be, especially if it works for the backends other than ODBC.

AG> // Example 3.
AG> void fill_ids(std::vector& ids)
AG> {
AG>for (std::size_t i = 0; i < ids.size(); ++i)
AG>   ids[i] = std::to_string(i); // mimics source of a new ID
AG> }
AG> 
AG> const int BATCH_SIZE = 25;
AG> std::vector ids(BATCH_SIZE);
AG> 
AG> statement st = (sql.prepare <<
AG> "insert into numbers(value) values(:val)",
AG> use(ids));
AG> for (int i = 0; i != 4; ++i)
AG> {
AG> fill_ids(ids);
AG> st.execute(true);
AG> }
AG> 
AG> In the ODBC backend, it seems to not bind directly to the strings, and at
AG> prepare time it copies the string data into a buffer, which isn't
AG> refreshed.

 It's not really obvious, however, how to fix this, i.e. at which time
should the data passed to ODBC be updated. I guess it needs to be done
before (every) call to execute() somehow.

 Regards,
VZ

pgpXSSq_mhPcR.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[soci-users] SOCI 4.0.1 released

[Vadim Zeitlin]

 Hello,

 We've just made available a new SOCI release, 4.0.1. In spite of a small
increase in the version number, this release contains quite a few changes
since 4.0.0, released almost a year ago, please see

https://github.com/SOCI/soci/blob/v4.0.1/CHANGES

for the list of the most important ones.

 The release archives are available at Source Forge:

https://sourceforge.net/projects/soci/files/soci/soci-4.0.1/soci-4.0.1.tar.gz
https://sourceforge.net/projects/soci/files/soci/soci-4.0.1/soci-4.0.1.zip

or also on GitHub, using v4.0.1 tag.

 The documentation for the latest release is available online at

http://soci.sourceforge.net/doc/release/4.0/

and also included in the release archives above.

 We'd like to thank the following people for contributing to this release:

- Alexander Kulikov
- Cavaler
- Denis Arnaud
- Dirk Vanden Boer
- Johan Pascal
- Matt Budish
- Rommel Trindade
- Ross Marwood
- Theo van Klaveren
- William Blough
- XiaoGuang Zeng
- Xuewen Wang
- Enrico Detoma

 We hope you will find this release useful!

Vadim Zeitlin on behalf of SOCI development team

pgpHjAPnvt2QE.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] update firebird 3.0 Win 10 MSVC 19

[Vadim Zeitlin]

On Thu, 13 May 2021 10:05:37 -0400 Jim McNamara  
wrote:

JM> It does not output an error. The code sample listed above
JM> doesn't execute cout << "2" . I don't use gdb for debugging.

 I think you should. Sorry, but there is clearly something very weird going
on your machine and you do need to debug it and understand what's going on,
nobody else can do it for you. If really can't use gdb, relax the class
used in your catch clause (i.e. use std::exception) and/or add "catch(...)"
to at least confirm that some other exception is being thrown. But using
a debugger should be simpler and faster to see what's going on.

JM> My mouse cursor briefly turns into the blue spinning wheel

 Watching the mouse cursor is not a productive debugging method.

 Good luck,
VZ

pgpGDijpt8I7Y.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] firebird quick question

[Vadim Zeitlin]

On Wed, 5 May 2021 04:51:58 -0400 Jim McNamara  
wrote:

JM> It doesn't want to print the value of count when I do a cout << count.

 You need to debug it to understand what's going on because the code looks
fine to me, but the first stupid question is whether it really doesn't
print them or if you just don't see them because you don't output a new
line after it.

 Regards,
VZ

pgpKfmBqS6CAo.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] SOCI API's-> ODBC backend -> MS SQL -> schema name -> table names.

[Vadim Zeitlin]

On Sun, 9 May 2021 21:16:04 -0500 Ravi chandra  wrote:

Rc> Hi SOCI developers,
Rc> 
Rc> [A] I had to change this string to get the Table names from MS SQL SERVER
Rc> default schema "dbo".
Rc> 
Rc> virtual std::string get_table_names_query() const
Rc> {
Rc> return "select table_name as \"Yummy_Data\""
Rc> " from information_schema.tables"
Rc> " where table_schema = '*dbo*'";
Rc> }
Rc> 
Rc> This returns all the Table names.

 This can't be done here (in session_backend) as it affects all backends,
but should be overridden in the ODBC backend code when using SQL Server
(there is already a function to do it, I think). If you can do it like
this, please create a PR implementing this and I'd be glad to merge it,
especially if it includes at least a simple unit test for the new
functionality.

 Thanks in advance,
VZ

pgpM0L9gbXWIm.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] update firebird 3.0 Win 10 MSVC 19

[Vadim Zeitlin]

On Tue, 11 May 2021 20:31:58 -0400 Jim McNamara  
wrote:

JM> Here is my output. I tried to neaten up my include code and I put in very
JM> basic debugging. It never gets past the connect string with the
JM> service, username, and password.

 What do you mean by this? Does it output an error (which one)? Crash?

JM> int main()
JM> {
JM> 
JM> int count2=0;
JM> try
JM> {
JM> 
JM> cout << "1";
JM> soci::session
JM> 
sql(backEnd,"service=c:/MYAPPS/firebird/firebird_3_0/examples/empbuild/EMPLOYEE.fdb
JM> user=sysdba password=mypasswd");
JM> cout << "2";
JM> sql << "select count(*) from employee", into(count2);
JM> }
JM> catch (soci_error const )
JM> {
JM> cerr << "Error: " << e.what() << '\n';
JM> }
JM> 
JM> return 0;
JM> }

 The code looks fine to me, so unless there is some subtle typo I'm missing
here, it can only be some problem with the build, e.g. maybe you've used a
different (and incompatible) version of Firebird in SOCI or something like
that.

 Also, just to be clear, I'm only using SOCI with embedded Firebird, not
the client-server version as we use it as a more compatible with the other
databases alternative to SQLite for purely local deployments, rather than
as an alternative to PostgreSQL or SQL Server. If you are using Firebird
server, there are probably a bunch of other reasons it might not work, but
I don't know anything about them, sorry.

 Regards,
VZ

pgp1KSmDUQicb.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Firebird backend

[Vadim Zeitlin]

On Mon, 3 May 2021 19:25:32 -0400 Jim McNamara  
wrote:

JM> Is soci able to be used with firebird 3.x?

 Yes, we use SOCI with Firebird 3 and it works perfectly fine.

 Regards,
VZ

pgp7alXGrKqqb.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[soci-users] Does anybody use DB/2 backend?

[Vadim Zeitlin]

 Hello,

 I'd like to know if anybody at all is using DB/2 backend. On one hand,
it's not very difficult to maintain it because it's very similar to the
ODBC backend which I'm interested in maintaining anyhow, but OTOH it would
still be simpler to drop it if it's not used, if only because I've failed
to set up a CI job for it on GitHub CI (the build images are too new and
can't use the binary DB/2 package used on Travis CI) and it's one of the
things which prevents us from migrating from Travis entirely.

 From the code maintenance point of view, an alternative solution could be
to try to merge DB/2 and ODBC backends together as they're 95% identical.
But this wouldn't address the CI problem and, again, while it could be
done, I'd like to know if there is any interest in the continued existence
of the DB/2 backend in the first place.

 Please let me know if you use, or plan to use, it. Thanks in advance!
VZ

pgpDNYSiqMznC.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[soci-users] Preparing for SOCI 4.0.2 release

[Vadim Zeitlin]

 Hello,

 I plan to officially announce 4.0.2 on April 19. I don't plan any more
changes right now, but the delay until then should hopefully give enough
time to find (and maybe fix) any bugs introduced by the latest round of
changes, so please try to test your code with the current master or
release/4.0 branch (which are almost identical) and report any bugs and
especially regressions.

 Thanks in advance,
VZ

pgpTeD56D8mX3.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[soci-users] SOCI 4.0.2 released

[Vadim Zeitlin]

 Hello,

 We've just made available a new SOCI release, 4.0.2. This release contains
many bug fixes and improvements, but is fully compatible with the previous
4.0.2 release. Please see

https://github.com/SOCI/soci/blob/v4.0.2/CHANGES

for the list of the most important changes.

 The release archives are available at Source Forge:

https://sourceforge.net/projects/soci/files/soci/soci-4.0.2/soci-4.0.2.tar.gz
https://sourceforge.net/projects/soci/files/soci/soci-4.0.2/soci-4.0.2.zip

or also on GitHub, using v4.0.2 tag.

 The documentation for the latest release is available online at

http://soci.sourceforge.net/doc/release/4.0/

and also included in the release archives above.

 We'd like to thank the following people for contributing to this release:

- alex (at staticlibs.net)
- Christian Kröhnert
- Cosmin Cremarenco
- Davy Durham
- gaocheng3 (at asiainfo.sg)
- George Rhoten
- Ilya Sinitsyn
- Ivan Kuvaldini
- Jiahao XU
- Jörn Reimerdes
- Kyle Edwards
- Mariana Meireles
- Noah Shutty
- root (at begeton.com)
- Thibault Martinez

 We hope you will find this release useful!

Vadim Zeitlin on behalf of SOCI development team

pgp2LUkV6Y7QT.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] MySQL / MariaDB bulk insert support.

[Vadim Zeitlin]

On Thu, 2 Sep 2021 10:04:45 +0100 Andrew Grafham  
wrote:

AG> I'm looking at this again and the backend with support for bulk operations
AG> is very different from the current MySQL version. In fact, the structure is
AG> more similar to the ODBC backend. I was wondering about having essentially
AG> 2 separate session implementations for MySQL, and instantiating the right
AG> one at runtime via the make_session factory method, based on what version
AG> of MySQL we have connected to. Does that sound reasonable?

 Hi,

 I am not sure if it's really worth having 2 separate session classes if
there is just one method which differs between them, but why not. You
would probably want to use a common base class to avoid duplicating the
common code between these classes, right?

 Regards,
VZ

pgpSdxAb0lMcQ.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] MySQL / MariaDB bulk insert support.

[Vadim Zeitlin]

On Thu, 5 Aug 2021 16:39:20 +0100 Andrew Grafham  
wrote:

AG> Are there any plans to add support for Array Binding (as mentioned
AG> here MYSQL_BIND
AG> - MariaDB Knowledge Base ) to the
AG> MySQL backend?

 I don't use MySQL myself currently, so I don't really have any motivation
for doing it, but if anybody does, any patches/PRs would be welcome, of
course, so please don't hesitate implementing this if you do need it.

 Thanks in advance,
VZ

pgplLJ3YTFG15.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] MySQL / MariaDB bulk insert support.

[Vadim Zeitlin]

On Mon, 9 Aug 2021 10:12:45 +0100 Andrew Grafham  
wrote:

AG> Any ideas how it would detect at runtime whether the server supports bulk
AG> operations or not?

 Sorry, no, I thought it would be just a server version check, but I
didn't realize it would be so problematic. And if there is some function
for checking the server capabilities in MySQL API, I'm not aware of it (but
then, again, I hardly know MySQL API at all, so this doesn't mean much).

AG> It's not very helpful - if you're using an older version of MySQL, and
AG> you create a statement and set its attribute STMT_ATTR_ARRAY_SIZE, it
AG> doesn't return an error until you actually try to execute the
AG> statement.

 Is this error understandable at least? I.e. is it immediately clear that
it's due to the server being too old? If it is, I guess we could also try
redoing the statement without STMT_ATTR_ARRAY_SIZE and set some internal
flag to not use it any more for the future requests. However this would be
much more complicated than just a version check, of course.

AG> It's not straightforward to add a check on the server's version number
AG> because you could be running against MySQL or MariaDB, and there is not
AG> a single version where it was added. E.g. MariaDB 10.2.3 had bulk
AG> operation support but then they removed it again until 10.2.7.

 FWIW I think it would be fine to just check for MariaDB >= 10.2.7 and not
bother with 10.2.{4,5,6} versions.

 Regards,
VZ

pgpkiTI9rjpBs.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] MySQL / MariaDB bulk insert support.

[Vadim Zeitlin]

On Fri, 6 Aug 2021 09:28:33 +0100 Andrew Grafham  
wrote:

AG> Would we need to keep backward compatibility with older versions of MariaDB
AG> that don't support Array Binding?

 Sorry, I really don't know much (well, anything) about M{y,aria}SQL API.
Which version added support for the array bindings? Are earlier versions
still in use?

AG> If so, how would you like it to determine whether to use Array Binding
AG> or not? Could we use a #define at compile time?

 We need compile-time checks as we don't want to break the library
compilation, but we probably also need run-time checks as I suspect that
nothing good will happen if you try to use this functionality with a server
which doesn't support it.

 Regards,
VZ

pgp_PopSTTVUN.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] cmake not working for me

[Vadim Zeitlin]

On Fri, 22 Oct 2021 22:44:48 -0400 Jim McNamara  
wrote:

JM> Hi all-
JM> I can't get the .sln file to appear so I can run msbuild.exe SOCI.sln.
JM> 
JM> cmake   -DSOCI_CXX11=ON -DWITH_BOOST=OFF -DWITH_ORACLE=OFF -DWITH_DB2=OFF
JM> -DWITH_MYSQL=OFF -DWITH_ODBC=OFF -DWITH_POSTGRESQL=OFF -DWITH_SQLITE3=OFF
JM> -DWITH_FIREBIRD=ON  -DFIREBIRD_INCLUDE_DIR="C:/Program
JM> Files/Firebird/Firebird_4_0/include" -DFIREBIRD_LIBRARIES="C:/Program
JM> Files/Firebird/Firebird_4_0/lib/fbclient_ms.lib"
JM> -DSOCI_FIREBIRD_TEST_CONNSTR:STRING="service=localhost:/Program
JM> Files/firebird/firebird_4_0/examples/empbuild/EMPLOYEE.FBD user=SYSDBA
JM> password=mypassword" ../
JM> 
JM> Is anyone else using visual studio 2019?

 Yes, SOCI builds with it without any problems. I don't understand what
exactly are you doing and having multiple messages about (apparently?) the
same problem doesn't help, but if you start from the beginning, i.e. clean
working tree and use the same commands as in appveyor.yml, you shouldn't
have any problems with building.

 Regards,
VZ

pgpXceSUJLQlp.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

[soci-users] SOCI 4.0.3 released

[Vadim Zeitlin]

 Hello,

 Latest SOCI release, 4.0.3, has just been made available. This release
contains several bug fixes but remains fully compatible with the previous
4.0.x releases and doesn't introduce any new requirements, so updating to
it should be quick and simple. Please see

https://github.com/SOCI/soci/blob/v4.0.3/CHANGES

for the list of the notable changes.

 The release archives are available at Source Forge:

https://sourceforge.net/projects/soci/files/soci/soci-4.0.3/soci-4.0.3.tar.gz
https://sourceforge.net/projects/soci/files/soci/soci-4.0.3/soci-4.0.3.zip

or also on GitHub, using v4.0.3 tag.

 The documentation for the latest release is available online at

http://soci.sourceforge.net/doc/release/4.0/

and also included in the release archives above.

 We'd like to thank the following people for contributing to this release:

Denis Arnaud
Dmitry Arkhipkin
gaocheng3 (at asiainfo.sg)
gypsy5oul
Ilya Sinitsyn
Juan Jose Castellanos
Lorenz Brun
Lukas Zanner
Mariana Meireles
Matheus Gabriel Werny de Lima
Mathäus Mendel

please see the AUTHORS file for the full list of contributors.

 We hope you will find this release useful!

Vadim Zeitlin on behalf of SOCI development team

pgpowtEq9QR0k.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Dynamic binding and prefetching

[Vadim Zeitlin]

On Tue, 18 Apr 2023 16:22:46 + LUCAS AYALA FRAGOSO 
 wrote:

LAF> I've got a question regarding dynamic binding and bulk operations
LAF> (only for DQLs). It is possible to do dynamic binding with bulk
LAF> operations in order to reduce network roundtrips?
LAF> 
LAF> I have to use the Core interface with `exchange_for_rowset`, but it
LAF> seems there is no option to do prefetching since the fetch size used
LAF> to call to the backend is determined by the size of the bind variables
LAF> (using vectors) and I can't provide such vectors. Is there any option
LAF> to do prefetching and dynamic binding?

 No, sorry, I don't think so, using vectors is the only form of performing
bulk operations that I know about.

 Regards,
VZ

pgpydB6E4Tp7I.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users

Re: [soci-users] Soci 4.0.3 in-source-build for windows/mac/linux (problem only in windows)

[Vadim Zeitlin]

On Tue, 25 Apr 2023 09:48:15 +0200 Tomaz Canabrava  wrote:

TC> My name is Tomaz Canabrava, I'm a Opensource developer mostly interested in
TC> contributing back to projects that I use.

 Hi Tomaz and welcome! I'm also an open source developer interested in
exactly the same thing, but this has somehow resulted me in maintaining
SOCI now :-/

TC> I forked a soci in github and I'm using version 4.0.3 to develop an
TC> application that should run in all major operating systems but it seems
TC> that the current mailine branch of soci has more modern CMake constructs
TC> than 4.0.3

 Unfortunately I don't know much about CMake and prefer to touch it as
little as possible. Thankfully there are other people who take care of it
in SOCI, mostly, but I'm afraid this means I won't be able to help you with
anything CMake-related.

TC> I had to hack around some issues that I found to be able to link Soci in
TC> linux / mac, as you can see in this patch. I also want to know if patches
TC> for 4.0.x are still accepted,

 Sure, I can merge PRs to 4.0, it's just that personally I don't have any
plans to work on it.

TC> if not, if it's safe to do a new release with current mailine branch or
TC> if the team needs help to finish what's needed for a new release.

 I really, really need to test the final version of the PR 954 and make a
new release once it's merged. But FWIW we do use current SOCI master in
production without any (known) problems, with multiple backends.

TC> But now on windows I'm having this issue:
TC> 
TC> error LNK2019: unresolved external symbol "struct
TC> soci::sqlite3_backend_factory const soci::sqlite3" (?sqlite3@soci
TC> @@3Usqlite3_backend_factory@1@B) referenced in function "public: bool
TC> __cdecl SociWriter::createOrOpen(class std::string const &)"
TC> (?createOrOpen@SociWriter@lvtmdb@Codethink@@QEAA_NAEBV?$basic_string@DU
TC> ?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)
TC> [C:\Project\Build\lvtmdb.vcxproj]
TC> 
TC> And I'm linking on all targets with:
TC> Soci::Core
TC> Soci::soci_sqlite3
TC> 
TC> (that are the names I exported via cmake ALIAS)
TC> 
TC> Any help is appreciated :)

 Are you using static or shared SOCI libraries? When using shared libraries
you shouldn't depend on this variable. When using static ones, it should be
found in the soci_sqlite3...

 Best regards,
VZ

pgpQQbIB5sq9_.pgp
Description: PGP signature
___
soci-users mailing list
soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users