Topic: N3612: Desiderata of a C++11 Database Interface


Author: tortoise741@gmail.com
Date: Tue, 2 Apr 2013 06:10:41 -0700 (PDT)
Raw View
------=_Part_1655_32476890.1364908241309
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

With regards to "N3612: Desiderata of a C++11 Database Interface",
the paper provides a useful review of several existing libraries but
focuses on important low level use cases rather than higher level
abstractions.
I believe a missing requirement is the easy creation of object relational
mapping classes. This was a key consideration for me in evaluating DTL
(partly as response to comments from java programmers using the JPA
suggesting it was not possible in C++)
For example I can define a structure like:

struct MyQueryResultType
{
   SomeType1 columnA;
   SomeType2 columnB;
};

and a mapping (a BCA in DTL parlance):

MyQueryResultType rowBuffer;

BCA(rowbuffer,
        COLS["columnA"] >> rowBuffer.columnA &&
        COLS["columnB"] >> rowBuffer.columnB)

This is enough to specify how to translate the databases types to and from
suitable C++ types. These mappings can be
provided or overloaded for individual queries to maximise performance, for
example by mapping to C++ types most closely matching their
database counterparts. Likewise generic mappings to less efficient but more
convenient types like strings can occur automagically.

Apologies if this is a repeat of something said in previous discussions. I
seems obvious to me but I have found no similar suggestions.

Regards,

Bruce.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1655_32476890.1364908241309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<br><br>With regards to "N3612: Desiderata of a C++11 Database Inter=
face", <br>the paper provides a useful review of several existing libraries=
 but focuses on important low level use cases rather than higher level abst=
ractions.<br>I believe a missing requirement is the easy creation of object=
 relational mapping classes. This was a key consideration for me in evaluat=
ing DTL<br>(partly as response to comments from java programmers using the =
JPA suggesting it was not possible in C++)<br>For example I can define a st=
ructure like:<br><br>struct MyQueryResultType<br>{<br>&nbsp;&nbsp; SomeType=
1 columnA;<br>&nbsp;&nbsp; SomeType2 columnB;<br>};<br><br>and a mapping (a=
 BCA in DTL parlance):<br><br>MyQueryResultType rowBuffer;<br><br>BCA(rowbu=
ffer,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; COLS["columnA"] &gt;&gt=
; rowBuffer.columnA &amp;&amp;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; COLS["columnB"] &gt;&gt; rowBuffer.columnB)<br><br>This is enough to spec=
ify how to translate the databases types to and from suitable C++ types. Th=
ese mappings can be <br>provided or overloaded for individual queries to ma=
ximise performance, for example by mapping to C++ types most closely matchi=
ng their<br>database counterparts. Likewise generic mappings to less effici=
ent but more convenient types like strings can occur automagically.<br><br>=
Apologies if this is a repeat of something said in previous discussions.
 I seems obvious to me but I have found no similar suggestions.<br><br>Rega=
rds,<br><br>Bruce.<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1655_32476890.1364908241309--

.


Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Tue, 2 Apr 2013 16:33:54 +0200
Raw View
--047d7b339bc37f501c04d961a02c
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have another comment about the document: it didn't take a look at cppdb
which is part of the cppcms framework.
http://cppcms.com/sql/cppdb/

Joel Lamotte

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--047d7b339bc37f501c04d961a02c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,=A0<div><br></div><div style>I have another comment abo=
ut the document: it didn&#39;t take a look at cppdb which is part of the cp=
pcms framework.</div><div style><a href=3D"http://cppcms.com/sql/cppdb/">ht=
tp://cppcms.com/sql/cppdb/</a><br>
</div><div style><br></div><div style>Joel Lamotte</div><div style><br></di=
v></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b339bc37f501c04d961a02c--

.


Author: DeadMG <wolfeinstein@gmail.com>
Date: Tue, 2 Apr 2013 07:46:01 -0700 (PDT)
Raw View
------=_Part_3554_3776831.1364913961657
Content-Type: text/plain; charset=ISO-8859-1

Frankly, at least compile-time reflection is required to make a decent
database interaction library.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_3554_3776831.1364913961657
Content-Type: text/html; charset=ISO-8859-1

Frankly, at least compile-time reflection is required to make a decent database interaction library.

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3554_3776831.1364913961657--

.


Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Tue, 2 Apr 2013 17:21:45 +0200
Raw View
--e89a8fb20244981f6204d9624b6d
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 2, 2013 at 4:46 PM, DeadMG <wolfeinstein@gmail.com> wrote:

> Frankly, at least compile-time reflection is required to make a decent
> database interaction library.


Isn't it required only for advanced/high level features? Having basics of
db access, like having basics of threading, would already be a good step
forward.

Joel Lamotte

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--e89a8fb20244981f6204d9624b6d
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 2, 2013 at 4:46 PM, DeadMG <span dir="ltr">&lt;<a href="mailto:wolfeinstein@gmail.com" target="_blank">wolfeinstein@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Frankly, at least compile-time reflection is required to make a decent database interaction library.</blockquote></div>
<br>Isn&#39;t it required only for advanced/high level features? Having basics of db access, like having basics of threading, would already be a good step forward.</div><div class="gmail_extra"><br></div><div class="gmail_extra" style>
Joel Lamotte</div><div class="gmail_extra" style><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--e89a8fb20244981f6204d9624b6d--

.


Author: Aleksandar Fabijanic <aleks.fabijanic@gmail.com>
Date: Tue, 2 Apr 2013 19:59:38 -0500
Raw View
--f46d04478533765d1b04d96a5f1e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The proposal is a step in the right direction; however, here's few
objections:

(page 4)
distinguishing statements from queries while treating the string passed for
execution as a "black box" is not universally possible; e.g. ODBC knows
only of statements; queries are statements and one can execute multiple
statements of which some are queries while other modify the database state
(and even select statements can modify DB state).

(page 5)
"a fully dynamic use case is probably more rare, as without any prior
knowledge about the result the application cannot do much except pass it to
the user as it is"

The proliferation of dynamic languages on the DB-driven web back-end is a
testimony that it is not at all rare, quite the contrary.
As for application not being able to do much but pass result as it is, see
e.g.
(
https://github.com/pocoproject/poco/blob/develop/Data/samples/RowFormatter/=
src/RowFormatter.cpp#L133)

Session session("SQLite", "sample.db");
std::cout << RecordSet(session, "SELECT * FROM Simpsons", new
HTMLTableFormatter);

One can easily imagine JSONFormatter, XMLFormatter etc ... and this is all
some environment with lots of small DB interactions needs. For larger
datasets, of course, static is the way to go, e.g.
(
https://github.com/pocoproject/poco/blob/develop/Data/samples/Tuple/src/Tup=
le.cpp#L50)

typedef Tuple<std::string, std::string, int> Person;
typedef std::vector<Person> People;

Session session("SQLite", "sample.db");

People people;
people.push_back(Person("Bart Simpson", "Springfield", 12));
people.push_back(Person("Lisa Simpson", "Springfield", 10));

Statement insert(session);
insert << "INSERT INTO Person VALUES(:name, :address, :age)", use(people), =
now;
people.clear();

Statement select(session);
select << "SELECT Name, Address, Age FROM Person", into(people), now;


But ... for really large datasets and bulk operations, only std::vector (of
PODs, less bool) binding makes sense.

On separation of compilation and execution and preliminary findings, it is
not correct that Poco::Data does not support it; it supports it where the
back end reasonably cooperates (e.g. ODBC). SQLite knows of no such thing
and will happily substitute NULLs for parameters not supplied at prepare
time.

On treating all databases the same, we've found it very hard to reconcile
different SQL back-ends behind a common interface - back ends behave
differently and some valuable specifics that users typically want/need are
lost. While SQL is hard, trying to put all the database engine paradigms
(SQL, noSQL, object, XML, ...) behind a single interface is, IMHO,
impossible; thus, we chose to introduce MongoDB interface as it's own
library in the upcoming 1.5.2 release:

https://github.com/pocoproject/poco/tree/develop/MongoDB

Regards,

Alex


On Tue, Apr 2, 2013 at 10:21 AM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com>=
wrote:

>
> On Tue, Apr 2, 2013 at 4:46 PM, DeadMG <wolfeinstein@gmail.com> wrote:
>
>> Frankly, at least compile-time reflection is required to make a decent
>> database interaction library.
>
>
> Isn't it required only for advanced/high level features? Having basics of
> db access, like having basics of threading, would already be a good step
> forward.
>
> Joel Lamotte
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=3Den.
>
>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



--f46d04478533765d1b04d96a5f1e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The proposal is a step in the right direction; however, he=
re&#39;s few objections:<div><br></div><div style>(page 4)</div><div>distin=
guishing statements from queries while treating the string passed for execu=
tion as a &quot;black box&quot; is not universally possible; e.g. ODBC know=
s only of statements; queries are=A0statements and one can execute multiple=
 statements of which some are queries while other modify the database state=
 (and even select statements can modify DB state).</div>

<div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">(page =
5)<br>&quot;a fully dynamic use case is probably more rare, as without any =
prior knowledge about the result the application cannot do much except pass=
 it to the user as it is&quot;</div>

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style>The p=
roliferation of dynamic languages on the DB-driven web back-end is a testim=
ony that it is not at all rare, quite the contrary.</div><div class=3D"gmai=
l_extra" style>

As for application not being able to do much but pass result as it is, see =
e.g.</div><div class=3D"gmail_extra" style>( <a href=3D"https://github.com/=
pocoproject/poco/blob/develop/Data/samples/RowFormatter/src/RowFormatter.cp=
p#L133">https://github.com/pocoproject/poco/blob/develop/Data/samples/RowFo=
rmatter/src/RowFormatter.cpp#L133</a> )<br>

</div><div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra"=
 style><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rg=
b(51,51,51);font-family:Consolas,&#39;Liberation Mono&#39;,Courier,monospac=
e;font-size:12px;line-height:16px;white-space:pre;background-color:rgb(255,=
255,255)">Session</span><span style=3D"color:rgb(51,51,51);font-family:Cons=
olas,&#39;Liberation Mono&#39;,Courier,monospace;font-size:12px;line-height=
:16px;white-space:pre"> </span><span class=3D"" style=3D"margin:0px;padding=
:0px;border:0px;color:rgb(51,51,51);font-family:Consolas,&#39;Liberation Mo=
no&#39;,Courier,monospace;font-size:12px;line-height:16px;white-space:pre;b=
ackground-color:rgb(255,255,255)">session</span><span class=3D"" style=3D"m=
argin:0px;padding:0px;border:0px;color:rgb(51,51,51);font-family:Consolas,&=
#39;Liberation Mono&#39;,Courier,monospace;font-size:12px;line-height:16px;=
white-space:pre">(</span><span class=3D"" style=3D"margin:0px;padding:0px;b=
order:0px;color:rgb(221,17,68);font-family:Consolas,&#39;Liberation Mono&#3=
9;,Courier,monospace;font-size:12px;line-height:16px;white-space:pre">&quot=
;SQLite&quot;</span><span class=3D"" style=3D"margin:0px;padding:0px;border=
:0px;color:rgb(51,51,51);font-family:Consolas,&#39;Liberation Mono&#39;,Cou=
rier,monospace;font-size:12px;line-height:16px;white-space:pre">,</span><sp=
an style=3D"color:rgb(51,51,51);font-family:Consolas,&#39;Liberation Mono&#=
39;,Courier,monospace;font-size:12px;line-height:16px;white-space:pre"> </s=
pan><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rgb(2=
21,17,68);font-family:Consolas,&#39;Liberation Mono&#39;,Courier,monospace;=
font-size:12px;line-height:16px;white-space:pre">&quot;sample.db&quot;</spa=
n><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rgb(51,=
51,51);font-family:Consolas,&#39;Liberation Mono&#39;,Courier,monospace;fon=
t-size:12px;line-height:16px;white-space:pre">);</span></div>

<div class=3D"gmail_extra" style><span class=3D"" style=3D"margin:0px;paddi=
ng:0px;border:0px;color:rgb(51,51,51);font-family:Consolas,&#39;Liberation =
Mono&#39;,Courier,monospace;font-size:12px;line-height:16px;white-space:pre=
">std</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;fon=
t-weight:bold;color:rgb(51,51,51);font-family:Consolas,&#39;Liberation Mono=
&#39;,Courier,monospace;font-size:12px;line-height:16px;white-space:pre">::=
</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rg=
b(51,51,51);font-family:Consolas,&#39;Liberation Mono&#39;,Courier,monospac=
e;font-size:12px;line-height:16px;white-space:pre">cout</span><span style=
=3D"color:rgb(51,51,51);font-family:Consolas,&#39;Liberation Mono&#39;,Cour=
ier,monospace;font-size:12px;line-height:16px;white-space:pre;background-co=
lor:rgb(255,255,204)"> </span><span class=3D"" style=3D"margin:0px;padding:=
0px;border:0px;font-weight:bold;color:rgb(51,51,51);font-family:Consolas,&#=
39;Liberation Mono&#39;,Courier,monospace;font-size:12px;line-height:16px;w=
hite-space:pre">&lt;&lt;</span><span style=3D"color:rgb(51,51,51);font-fami=
ly:Consolas,&#39;Liberation Mono&#39;,Courier,monospace;font-size:12px;line=
-height:16px;white-space:pre;background-color:rgb(255,255,204)"> </span><sp=
an class=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rgb(51,51,51=
);font-family:Consolas,&#39;Liberation Mono&#39;,Courier,monospace;font-siz=
e:12px;line-height:16px;white-space:pre">RecordSet</span><span class=3D"" s=
tyle=3D"margin:0px;padding:0px;border:0px;color:rgb(51,51,51);font-family:C=
onsolas,&#39;Liberation Mono&#39;,Courier,monospace;font-size:12px;line-hei=
ght:16px;white-space:pre">(</span><span class=3D"" style=3D"margin:0px;padd=
ing:0px;border:0px;color:rgb(51,51,51);font-family:Consolas,&#39;Liberation=
 Mono&#39;,Courier,monospace;font-size:12px;line-height:16px;white-space:pr=
e">session</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0p=
x;color:rgb(51,51,51);font-family:Consolas,&#39;Liberation Mono&#39;,Courie=
r,monospace;font-size:12px;line-height:16px;white-space:pre">,</span><span =
style=3D"color:rgb(51,51,51);font-family:Consolas,&#39;Liberation Mono&#39;=
,Courier,monospace;font-size:12px;line-height:16px;white-space:pre;backgrou=
nd-color:rgb(255,255,204)"> </span><span class=3D"" style=3D"margin:0px;pad=
ding:0px;border:0px;color:rgb(221,17,68);font-family:Consolas,&#39;Liberati=
on Mono&#39;,Courier,monospace;font-size:12px;line-height:16px;white-space:=
pre">&quot;SELECT * FROM Simpsons&quot;</span><span class=3D"" style=3D"mar=
gin:0px;padding:0px;border:0px;color:rgb(51,51,51);font-family:Consolas,&#3=
9;Liberation Mono&#39;,Courier,monospace;font-size:12px;line-height:16px;wh=
ite-space:pre">,</span><span style=3D"color:rgb(51,51,51);font-family:Conso=
las,&#39;Liberation Mono&#39;,Courier,monospace;font-size:12px;line-height:=
16px;white-space:pre;background-color:rgb(255,255,204)"> </span><span class=
=3D"" style=3D"margin:0px;padding:0px;border:0px;font-weight:bold;color:rgb=
(51,51,51);font-family:Consolas,&#39;Liberation Mono&#39;,Courier,monospace=
;font-size:12px;line-height:16px;white-space:pre">new</span><span style=3D"=
color:rgb(51,51,51);font-family:Consolas,&#39;Liberation Mono&#39;,Courier,=
monospace;font-size:12px;line-height:16px;white-space:pre;background-color:=
rgb(255,255,204)"> </span><span class=3D"" style=3D"margin:0px;padding:0px;=
border:0px;color:rgb(51,51,51);font-family:Consolas,&#39;Liberation Mono&#3=
9;,Courier,monospace;font-size:12px;line-height:16px;white-space:pre">HTMLT=
ableFormatter</span><span class=3D"" style=3D"margin:0px;padding:0px;border=
:0px;color:rgb(51,51,51);font-family:Consolas,&#39;Liberation Mono&#39;,Cou=
rier,monospace;font-size:12px;line-height:16px;white-space:pre">);</span></=
div>

<div class=3D"gmail_extra"><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_quote" style>One can easily imagine JSONFormatter, XMLFormatter e=
tc ... and this is all some environment with lots of small DB interactions =
needs. For larger datasets, of course, static is the way to go, e.g.=A0</di=
v>

<div class=3D"gmail_quote" style>( <a href=3D"https://github.com/pocoprojec=
t/poco/blob/develop/Data/samples/Tuple/src/Tuple.cpp#L50">https://github.co=
m/pocoproject/poco/blob/develop/Data/samples/Tuple/src/Tuple.cpp#L50</a> )<=
/div>

<div class=3D"gmail_quote" style><br></div><div class=3D"gmail_quote" style=
><pre style=3D"margin-top:0px;margin-bottom:0px;padding:0px;border:0px;font=
-size:12px;font-family:Consolas,&#39;Liberation Mono&#39;,Courier,monospace=
;color:rgb(51,51,51);line-height:16px">

<div class=3D"" id=3D"LC50" style=3D"margin:0px;padding:0px 0px 0px 10px;bo=
rder:0px"><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;font-=
weight:bold">typedef</span> <span class=3D"" style=3D"margin:0px;padding:0p=
x;border:0px">Tuple</span><span class=3D"" style=3D"margin:0px;padding:0px;=
border:0px;font-weight:bold">&lt;</span><span class=3D"" style=3D"margin:0p=
x;padding:0px;border:0px">std</span><span class=3D"" style=3D"margin:0px;pa=
dding:0px;border:0px;font-weight:bold">::</span><span class=3D"" style=3D"m=
argin:0px;padding:0px;border:0px">string</span><span class=3D"" style=3D"ma=
rgin:0px;padding:0px;border:0px">,</span> <span class=3D"" style=3D"margin:=
0px;padding:0px;border:0px">std</span><span class=3D"" style=3D"margin:0px;=
padding:0px;border:0px;font-weight:bold">::</span><span class=3D"" style=3D=
"margin:0px;padding:0px;border:0px">string</span><span class=3D"" style=3D"=
margin:0px;padding:0px;border:0px">,</span> <span class=3D"" style=3D"margi=
n:0px;padding:0px;border:0px;color:rgb(68,85,136);font-weight:bold">int</sp=
an><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;font-weight:=
bold">&gt;</span> <span class=3D"" style=3D"margin:0px;padding:0px;border:0=
px">Person</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0p=
x">;</span></div>

<div class=3D"" id=3D"LC51" style=3D"margin:0px;padding:0px 0px 0px 10px;bo=
rder:0px"><span class=3D"" style=3D"margin:0px;padding:0px;border:0px;font-=
weight:bold">typedef</span> <span class=3D"" style=3D"margin:0px;padding:0p=
x;border:0px">std</span><span class=3D"" style=3D"margin:0px;padding:0px;bo=
rder:0px;font-weight:bold">::</span><span class=3D"" style=3D"margin:0px;pa=
dding:0px;border:0px">vector</span><span class=3D"" style=3D"margin:0px;pad=
ding:0px;border:0px;font-weight:bold">&lt;</span><span class=3D"" style=3D"=
margin:0px;padding:0px;border:0px">Person</span><span class=3D"" style=3D"m=
argin:0px;padding:0px;border:0px;font-weight:bold">&gt;</span> <span class=
=3D"" style=3D"margin:0px;padding:0px;border:0px">People</span><span class=
=3D"" style=3D"margin:0px;padding:0px;border:0px">;</span></div>

<div class=3D"" id=3D"LC52" style=3D"margin:0px;padding:0px 0px 0px 10px;bo=
rder:0px"><span class=3D"" style=3D"margin:0px;padding:0px;border:0px"><br>=
</span></div><div class=3D"" id=3D"LC52" style=3D"margin:0px;padding:0px 0p=
x 0px 10px;border:0px">

<span class=3D"" style=3D"margin:0px;padding:0px;border:0px">Session</span>=
 <span class=3D"" style=3D"margin:0px;padding:0px;border:0px">session</span=
><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">(</span><span=
 class=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rgb(221,17,68)=
">&quot;SQLite&quot;</span><span class=3D"" style=3D"margin:0px;padding:0px=
;border:0px">,</span> <span class=3D"" style=3D"margin:0px;padding:0px;bord=
er:0px;color:rgb(221,17,68)">&quot;sample.db&quot;</span><span class=3D"" s=
tyle=3D"margin:0px;padding:0px;border:0px">);</span><br>

</div></pre></div><div class=3D"gmail_quote" style><pre style=3D"margin-top=
:0px;margin-bottom:0px;padding:0px;border:0px;font-size:12px;font-family:Co=
nsolas,&#39;Liberation Mono&#39;,Courier,monospace;color:rgb(51,51,51);line=
-height:16px">

<div class=3D"" id=3D"LC63" style=3D"margin:0px;padding:0px 0px 0px 10px;bo=
rder:0px"><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">Peop=
le</span> <span class=3D"" style=3D"margin:0px;padding:0px;border:0px">peop=
le</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">;</sp=
an></div>

<div class=3D"" id=3D"LC64" style=3D"margin:0px;padding:0px 0px 0px 10px;bo=
rder:0px"><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">peop=
le</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">.</sp=
an><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">push_back</=
span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">(</span><=
span class=3D"" style=3D"margin:0px;padding:0px;border:0px">Person</span><s=
pan class=3D"" style=3D"margin:0px;padding:0px;border:0px">(</span><span cl=
ass=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rgb(221,17,68)">&=
quot;Bart Simpson&quot;</span><span class=3D"" style=3D"margin:0px;padding:=
0px;border:0px">,</span> <span class=3D"" style=3D"margin:0px;padding:0px;b=
order:0px;color:rgb(221,17,68)">&quot;Springfield&quot;</span><span class=
=3D"" style=3D"margin:0px;padding:0px;border:0px">,</span> <span class=3D""=
 style=3D"margin:0px;padding:0px;border:0px;color:rgb(0,153,153)">12</span>=
<span class=3D"" style=3D"margin:0px;padding:0px;border:0px">));</span></di=
v>

<div class=3D"" id=3D"LC65" style=3D"margin:0px;padding:0px 0px 0px 10px;bo=
rder:0px"><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">peop=
le</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">.</sp=
an><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">push_back</=
span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">(</span><=
span class=3D"" style=3D"margin:0px;padding:0px;border:0px">Person</span><s=
pan class=3D"" style=3D"margin:0px;padding:0px;border:0px">(</span><span cl=
ass=3D"" style=3D"margin:0px;padding:0px;border:0px;color:rgb(221,17,68)">&=
quot;Lisa Simpson&quot;</span><span class=3D"" style=3D"margin:0px;padding:=
0px;border:0px">,</span> <span class=3D"" style=3D"margin:0px;padding:0px;b=
order:0px;color:rgb(221,17,68)">&quot;Springfield&quot;</span><span class=
=3D"" style=3D"margin:0px;padding:0px;border:0px">,</span> <span class=3D""=
 style=3D"margin:0px;padding:0px;border:0px;color:rgb(0,153,153)">10</span>=
<span class=3D"" style=3D"margin:0px;padding:0px;border:0px">));</span></di=
v>

<div class=3D"" id=3D"LC66" style=3D"margin:0px;padding:0px 0px 0px 10px;bo=
rder:0px"><br></div><div class=3D"" id=3D"LC67" style=3D"margin:0px;padding=
:0px 0px 0px 10px;border:0px"><span class=3D"" style=3D"margin:0px;padding:=
0px;border:0px">Statement</span> <span class=3D"" style=3D"margin:0px;paddi=
ng:0px;border:0px">insert</span><span class=3D"" style=3D"margin:0px;paddin=
g:0px;border:0px">(</span><span class=3D"" style=3D"margin:0px;padding:0px;=
border:0px">session</span><span class=3D"" style=3D"margin:0px;padding:0px;=
border:0px">);</span></div>

<div class=3D"" id=3D"LC68" style=3D"margin:0px;padding:0px 0px 0px 10px;bo=
rder:0px"><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">inse=
rt</span> <span class=3D"" style=3D"margin:0px;padding:0px;border:0px;font-=
weight:bold">&lt;&lt;</span> <span class=3D"" style=3D"margin:0px;padding:0=
px;border:0px;color:rgb(221,17,68)">&quot;INSERT INTO Person VALUES(:name, =
:address, :age)&quot;</span><span class=3D"" style=3D"margin:0px;padding:0p=
x;border:0px">, </span><span class=3D"" style=3D"margin:0px;padding:0px;bor=
der:0px">use</span><span class=3D"" style=3D"margin:0px;padding:0px;border:=
0px">(</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">p=
eople</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">),=
</span> <span class=3D"" style=3D"margin:0px;padding:0px;border:0px">now</s=
pan><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">;</span></=
div>

<div class=3D"" id=3D"LC70" style=3D"margin:0px;padding:0px 0px 0px 10px;bo=
rder:0px"><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">peop=
le</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">.</sp=
an><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">clear</span=
><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">();</span><br=
>

</div><div class=3D"" id=3D"LC72" style=3D"margin:0px;padding:0px 0px 0px 1=
0px;border:0px"><br></div><div class=3D"" id=3D"LC73" style=3D"margin:0px;p=
adding:0px 0px 0px 10px;border:0px"><span class=3D"" style=3D"margin:0px;pa=
dding:0px;border:0px">Statement</span> <span class=3D"" style=3D"margin:0px=
;padding:0px;border:0px">select</span><span class=3D"" style=3D"margin:0px;=
padding:0px;border:0px">(</span><span class=3D"" style=3D"margin:0px;paddin=
g:0px;border:0px">session</span><span class=3D"" style=3D"margin:0px;paddin=
g:0px;border:0px">);</span></div>

<div class=3D"" id=3D"LC73" style=3D"margin:0px;padding:0px 0px 0px 10px;bo=
rder:0px"><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">sele=
ct</span> <span class=3D"" style=3D"margin:0px;padding:0px;border:0px;font-=
weight:bold">&lt;&lt;</span> <span class=3D"" style=3D"margin:0px;padding:0=
px;border:0px;color:rgb(221,17,68)">&quot;SELECT Name, Address, Age FROM Pe=
rson&quot;</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0p=
x">, </span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">in=
to</span><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">(</sp=
an><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">people</spa=
n><span class=3D"" style=3D"margin:0px;padding:0px;border:0px">), </span><s=
pan class=3D"" style=3D"margin:0px;padding:0px;border:0px">now</span><span =
class=3D"" style=3D"margin:0px;padding:0px;border:0px">;</span></div>

</pre></div><div class=3D"gmail_quote" style><br></div><div class=3D"gmail_=
quote" style>But ... for really large datasets and bulk operations, only st=
d::vector (of PODs, less bool) binding makes sense.</div><div class=3D"gmai=
l_quote" style>

<br></div><div class=3D"gmail_quote" style>On separation of compilation and=
 execution and preliminary findings, it is not correct that Poco::Data does=
 not support it; it supports it where the back end reasonably cooperates (e=
..g. ODBC). SQLite knows of no such thing and will=A0happily=A0substitute NU=
LLs for=A0parameters=A0not supplied at prepare time.</div>

<div class=3D"gmail_quote" style><br></div><div class=3D"gmail_quote" style=
>On treating all databases the same, we&#39;ve found=A0it very hard to reco=
ncile different SQL back-ends behind a common interface - back ends behave =
differently and some valuable specifics that users typically want/need are =
lost. While SQL is hard, trying to put all the database engine paradigms (S=
QL, noSQL, object, XML, ...) behind a single interface is, IMHO, impossible=
; thus, we chose to introduce MongoDB interface as it&#39;s own library in =
the upcoming 1.5.2 release:</div>

<div class=3D"gmail_quote" style><br></div><div class=3D"gmail_quote" style=
><a href=3D"https://github.com/pocoproject/poco/tree/develop/MongoDB">https=
://github.com/pocoproject/poco/tree/develop/MongoDB</a><br></div><div class=
=3D"gmail_quote" style>

<br></div><div class=3D"gmail_quote" style>Regards,</div><div class=3D"gmai=
l_quote" style><br></div><div class=3D"gmail_quote" style>Alex</div><div cl=
ass=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></div><div cla=
ss=3D"gmail_quote">

On Tue, Apr 2, 2013 at 10:21 AM, Klaim - Jo=EBl Lamotte <span dir=3D"ltr">&=
lt;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"im"><br><div clas=
s=3D"gmail_quote">On Tue, Apr 2, 2013 at 4:46 PM, DeadMG <span dir=3D"ltr">=
&lt;<a href=3D"mailto:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstei=
n@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Frankly, at least compile-time reflection is required to m=
ake a decent database interaction library.</blockquote>

</div>
<br></div>Isn&#39;t it required only for advanced/high level features? Havi=
ng basics of db access, like having basics of threading, would already be a=
 good step forward.</div><div class=3D"gmail_extra"><br></div><div class=3D=
"gmail_extra">


Joel Lamotte</div><div class=3D"gmail_extra"><br></div></div><div class=3D"=
"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--f46d04478533765d1b04d96a5f1e--

.


Author: DeadMG <wolfeinstein@gmail.com>
Date: Wed, 3 Apr 2013 06:18:29 -0700 (PDT)
Raw View
------=_Part_6369_31020091.1364995109703
Content-Type: text/plain; charset=ISO-8859-1


>
> The proliferation of dynamic languages on the DB-driven web back-end is a
> testimony that


people wish to hack together websites in the minimal amount of time, and
has absolutely nothing whatsoever to do with the dynamism of the database
access. He is quite correct that an application needs to know the database
schema in order to put the result to any use.

Also, your use of raw new embarrasses me.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_6369_31020091.1364995109703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">The proliferation of dynamic languages on the =
DB-driven web back-end is a testimony that</blockquote><div><br></div><div>=
people wish to hack together websites in the minimal amount of time, and ha=
s absolutely nothing whatsoever to do with the dynamism of the database acc=
ess. He is quite correct that an application needs to know the database sch=
ema in order to put the result to any use.</div><div><br></div><div>Also, y=
our use of raw new embarrasses me. &nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_6369_31020091.1364995109703--

.


Author: Aleksandar Fabijanic <aleks.fabijanic@gmail.com>
Date: Wed, 3 Apr 2013 10:21:32 -0500
Raw View
--089e01182c20dda5c104d976696b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 3, 2013 at 8:18 AM, DeadMG <wolfeinstein@gmail.com> wrote:

> He is quite correct that an application needs to know the database schema
>> in order to put the result to any use.
>
>
In some cases, yes. Always, not.


> Also, your use of raw new embarrasses me.
>

There's nothing wrong with the new, especially in the context of C++03 when
the code was written. Ther would be something wrong if I had to explicitly
call delete somewhere later.

If you look up boost::shared_ptr (which is now C++11) "Best Practices",
you'll find the same thing:

http://www.boost.org/doc/libs/1_53_0/libs/smart_ptr/shared_ptr.htm

shared_ptr<X> p1( new X );

Alex


>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--089e01182c20dda5c104d976696b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Apr 3, 2013 at 8:18 AM, DeadMG <span dir=3D"ltr">&=
lt;<a href=3D"mailto:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein=
@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">

<span style=3D"color:rgb(34,34,34)">He is quite correct that an application=
 needs to know the database schema in order to put the result to any use.</=
span></blockquote></div></blockquote><div><br></div><div style>In some case=
s, yes. Always, not.</div>

<div style>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div>Also, your use of raw new embarra=
sses me. =A0</div>

</blockquote><div><br></div><div style>There&#39;s nothing wrong with the n=
ew,=A0especially=A0in the context of C++03 when the code was written. Ther =
would be something wrong if I had to explicitly call delete somewhere later=
..</div>

<div style><br></div><div style>If you look up boost::shared_ptr (which is =
now C++11) &quot;Best Practices&quot;, you&#39;ll find the same thing:</div=
><div style><br></div><div style><a href=3D"http://www.boost.org/doc/libs/1=
_53_0/libs/smart_ptr/shared_ptr.htm">http://www.boost.org/doc/libs/1_53_0/l=
ibs/smart_ptr/shared_ptr.htm</a></div>

<div style><pre style=3D"color:rgb(0,0,0)">shared_ptr&lt;X&gt; p1( new X );=
</pre></div><div style>Alex</div><div>=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class=3D""><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e01182c20dda5c104d976696b--

.


Author: Aleksandar Fabijanic <aleks.fabijanic@gmail.com>
Date: Wed, 3 Apr 2013 11:14:30 -0500
Raw View
--f46d04478533503f3404d9772701
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 3, 2013 at 8:18 AM, DeadMG <wolfeinstein@gmail.com> wrote:

> The proliferation of dynamic languages on the DB-driven web back-end is a
>> testimony that
>
>
> people wish to hack together websites in the minimal amount of time, and
> has absolutely nothing whatsoever to do with the dynamism of the database
> access.
>

In regards to schema and types, formats like e.g. JSON are
self-descriptive. The "heavy lifting" of type and layout discovery can be
done automatically in the background, while application logic can and
should be (unless performance penalty is prohibitively high) built around
more "user friendly" formats, rather than rigidly coupling compiled code to
DB schema layout and static types. Lots of utility functionality
(formatting, filtering, logging, events ...) can be dynamically plugged-in
through a generic handler pattern.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--f46d04478533503f3404d9772701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Apr 3, 2013 at 8:18 AM, DeadMG <span dir=3D"ltr">&=
lt;<a href=3D"mailto:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein=
@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">

The proliferation of dynamic languages on the DB-driven web back-end is a t=
estimony that</blockquote><div><br></div></div><div>people wish to hack tog=
ether websites in the minimal amount of time, and has absolutely nothing wh=
atsoever to do with the dynamism of the database access.=A0</div>

</blockquote><div><br></div><div>In regards to schema and types, formats li=
ke e.g. JSON are self-descriptive. The &quot;heavy lifting&quot; of type an=
d layout discovery can be done automatically in the background, while appli=
cation logic can and should be (unless=A0performance=A0penalty is prohibiti=
vely high) built around more &quot;user friendly&quot; formats,=A0rather=A0=
than rigidly coupling compiled code to DB schema layout and static types. L=
ots of utility functionality (formatting, filtering, logging, events ...) c=
an be dynamically plugged-in through a generic handler pattern.</div>

</div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--f46d04478533503f3404d9772701--

.


Author: Aleksandar Fabijanic <aleks.fabijanic@gmail.com>
Date: Wed, 3 Apr 2013 13:09:52 -0500
Raw View
--14dae93a0d95db641c04d978c30a
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 3, 2013 at 10:21 AM, Aleksandar Fabijanic <
aleks.fabijanic@gmail.com> wrote:

> On Wed, Apr 3, 2013 at 8:18 AM, DeadMG <wolfeinstein@gmail.com> wrote:
>
>
>> Also, your use of raw new embarrasses me.
>>
>
I thought you meant just using new but now I see now what you refer to -
the potential leak due to evaluation/construction order. That allocation
should indeed be wrapped in std::make_shared (or equivalent).

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--14dae93a0d95db641c04d978c30a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Apr 3, 2013 at 10:21 AM, Aleksandar Fabijanic <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:aleks.fabijanic@gmail.com" target=3D"_b=
lank">aleks.fabijanic@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmai=
l_extra">

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"im">On Wed, Apr 3, 2013 at 8:18 AM, DeadMG <span dir=3D"ltr">=
&lt;<a href=3D"mailto:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstei=
n@gmail.com</a>&gt;</span> wrote:</div>

<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im">
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div>Also, your use of raw new embarrasses m=
e. =A0</div>

</blockquote></div></div></div></div></blockquote><div><br></div><div style=
>I thought you meant just using new but now I see now what you refer to - t=
he potential leak due to evaluation/construction order. That allocation sho=
uld indeed=A0be=A0wrapped=A0in std::make_shared (or equivalent).=A0</div>

</div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--14dae93a0d95db641c04d978c30a--

.


Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 3 Apr 2013 15:50:36 -0700 (PDT)
Raw View
------=_Part_1_25152698.1365029436764
Content-Type: text/plain; charset=ISO-8859-1

> int value;
> for (auto row:db.query(querystring,123).into(value))
>   cerr << value << endl;

I'd prefer not having to declare vars before the loop.

for (auto row : db.query(querystring, 23))
  cerr << row[0] << endl;

or

  cerr << row["value"] << endl;

Async query execution should be covered.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1_25152698.1365029436764
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>&gt; int value;</div><div>&gt; for (auto row:db.query(querystring,123)=
..into(value))</div><div>&gt; &nbsp;&nbsp;cerr &lt;&lt; value &lt;&lt; endl;=
</div><div><br></div><div><div>I'd prefer not having to declare vars before=
 the loop.</div><div><br></div><div>for (auto row : db.query(querystring, 2=
3))</div><div>&nbsp; cerr &lt;&lt; row[0] &lt;&lt; endl;</div><div><br></di=
v></div><div>or&nbsp;</div><div><br></div><div>&nbsp; cerr &lt;&lt; row["va=
lue"] &lt;&lt; endl;<br></div><div><br></div><div>Async query execution sho=
uld be covered.</div><div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1_25152698.1365029436764--

.


Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 3 Apr 2013 15:52:47 -0700 (PDT)
Raw View
------=_Part_359_23985647.1365029567160
Content-Type: text/plain; charset=ISO-8859-1

> std :: string name;
> for (auto row:query(1234).into(name))
>   cout << name << endl;

I'd prefer not having to declare vars before the loop.

for (auto row:query(1234))
  cout << row["name"] << endl;
or
  cout << row[0] << endl;

Async query execution should be covered too.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_359_23985647.1365029567160
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>&gt; std :: string name;</div><div>&gt; for (auto row:query(1234).into=
(name))</div><div>&gt; &nbsp; cout &lt;&lt; name &lt;&lt; endl;</div><div><=
br></div><div>I'd prefer not having to declare vars before the loop.</div><=
div><br></div><div><div>for (auto row:query(1234))</div><div>&nbsp; cout &l=
t;&lt; row["name"] &lt;&lt; endl;</div></div><div>or</div><div>&nbsp; cout =
&lt;&lt; row[0] &lt;&lt; endl;<br></div><div><br></div><div>Async query exe=
cution should be covered too.</div><div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_359_23985647.1365029567160--

.


Author: Aleksandar Fabijanic <aleks.fabijanic@gmail.com>
Date: Wed, 3 Apr 2013 18:43:59 -0500
Raw View
--e89a8fb1f7a6ca278604d97d6eae
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 3, 2013 at 5:52 PM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> > std :: string name;
> > for (auto row:query(1234).into(name))
> >   cout << name << endl;
>
> I'd prefer not having to declare vars before the loop.
>

due to performance concerns associated with dynamic type discovery, both
options should be available

Async query execution should be covered too.
>

+1

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--e89a8fb1f7a6ca278604d97d6eae
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Apr 3, 2013 at 5:52 PM, Olaf van der Spek <span di=
r=3D"ltr">&lt;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">ola=
fvdspek@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>&gt; std :: string name;</div><div>&gt;=
 for (auto row:query(1234).into(name))</div><div>&gt; =A0 cout &lt;&lt; nam=
e &lt;&lt; endl;</div>

<div class=3D"im"><div><br></div><div>I&#39;d prefer not having to declare =
vars before the loop.</div></div></blockquote><div><br></div><div style>due=
 to performance concerns associated with dynamic type discovery, both optio=
ns=A0should=A0be available</div>

<div style><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Async query execut=
ion should be covered too.</div></blockquote><div><br></div><div>+1</div><d=
iv>

=A0</div></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--e89a8fb1f7a6ca278604d97d6eae--

.


Author: harris.pc@gmail.com
Date: Wed, 10 Apr 2013 17:25:11 -0700 (PDT)
Raw View
------=_Part_260_6507149.1365639911341
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, April 2, 2013 9:10:41 PM UTC+8, torto...@gmail.com wrote:
>
> Hi all,
>
> With regards to "N3612: Desiderata of a C++11 Database Interface",
> the paper provides a useful review of several existing libraries but
> focuses on important low level use cases rather than higher level
> abstractions.
> I believe a missing requirement is the easy creation of object relational
> mapping classes. This was a key consideration for me in evaluating DTL
>
>
I started with the DTL and using object-relational mapping, but my use-case
requires bulk of millions of rows plus strict type handling.  I was not
able to take the DTL all the way, and the other libraries I looked at
weren't appropriate in one way or another.

I wrote my own little ODBC-wrapping C++ library (about 3k lines) that
manages the bulk loading through ODBC, with exception, thread and type
safety, with as efficient loading as I could get.
Its only used in one of my projects on MySQL, Sqlite and Oracle databases.

It loads chunks into its own buffer (which manages nulls, type variations
and bugs eg Oracle uses int32 rather than the standard's int16 in some
cases).  It generates the buffer appropriate for the column discovered
(dynamically) by the query, so its easy enough to use it with dynamic or
static queries.

Data can then be sucked out of the buffers via efficient
boost::static_visitor based Visitors, which allows me to be specific about
what to do when translating from eg floating point to integer.  (and allows
me to eg just print stuff out if its being used in a dynamic
print-to-screen usecase).

If someone has an interest, I can pop the library online.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_260_6507149.1365639911341
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, April 2, 2013 9:10:41 PM UTC+8, torto...@gmail.com wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Hi all,<br><br>With regards =
to "N3612: Desiderata of a C++11 Database Interface", <br>the paper provide=
s a useful review of several existing libraries but focuses on important lo=
w level use cases rather than higher level abstractions.<br>I believe a mis=
sing requirement is the easy creation of object relational mapping classes.=
 This was a key consideration for me in evaluating DTL<br><br></blockquote>=
<div><br></div><div>I started with the DTL and using object-relational mapp=
ing, but my use-case requires bulk of millions of rows plus strict type han=
dling. &nbsp;I was not able to take the DTL all the way, and the other libr=
aries I looked at weren't appropriate in one way or another.</div><div><br>=
</div><div>I wrote my own little ODBC-wrapping C++ library (about 3k lines)=
 that manages the bulk loading through ODBC, with exception, thread and typ=
e safety, with as efficient loading as I could get.</div><div>Its only used=
 in one of my projects on MySQL, Sqlite and Oracle databases.</div><div><br=
></div><div>It loads chunks into its own buffer (which manages nulls, type =
variations and bugs eg Oracle uses int32 rather than the standard's int16 i=
n some cases). &nbsp;It generates the buffer appropriate for the column dis=
covered (dynamically) by the query, so its easy enough to use it with dynam=
ic or static queries.</div><div><br></div><div>Data can then be sucked out =
of the buffers via efficient boost::static_visitor based Visitors, which al=
lows me to be specific about what to do when translating from eg floating p=
oint to integer. &nbsp;(and allows me to eg just print stuff out if its bei=
ng used in a dynamic print-to-screen usecase).</div><div><br></div><div>If =
someone has an interest, I can pop the library online.</div><div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_260_6507149.1365639911341--

.


Author: corwinjoy@gmail.com
Date: Wed, 10 Apr 2013 22:35:08 -0700 (PDT)
Raw View
------=_Part_445_8282894.1365658508233
Content-Type: text/plain; charset=ISO-8859-1

As one of the authors of DTL I wanted to make a few comments here.

A.
First, the specification laid out here is very query-centric.  In contrast,
the goal of DTL is to avoid writing
raw queries when we can.  Instead, the idea of DTL is

1. Define a struct to hold row data.
2. Define a mapping from fields in the struct to fields in a table. (An
object-relational mapping or ORM).
3. Create a C++ standard compliant container from the struct + ORM.  Loop
through the container to read rows,
assign to the container to update rows, add/remove from the container to
insert and delete rows.

In the DTL setting using raw queries is the exception rather than the rule
- although we do have support for general queries.

There are some positive features to this design:

1. Using physical structs (we also support classes) is memory efficient and
gives fast code.  When you access a field via an
expression like Employee.Salary there is no overhead.
2. A container interface is a natural way to think about a table.
3. We were able to provide a clean and concise syntax for mapping fields in
a structure to fields in a table.
This facilitates easy generation and maintenance of any database mappings.


B.
There are other well known database libraries which provide a similar
abstraction. One famous example that is well worth
examining is the Java Hibernate library:
http://en.wikipedia.org/wiki/Hibernate_(Java).

C.
The code samples given by the author mostly seem to loop over the result
set from a query.  For example:
for(auto row:query()) {
  // do something with each row
}

In the ODBC world there are at least two usage cases that cause problems
for this model.
1. Stored procedures can return multiple result sets.
2. For efficiency, bulk operations are important in ODBC. These can be over
100x faster than row-wise operations
and typically operate on an array of POD type data "all-at-once".

D.
The dynamic use case given in the paper is important, but requires careful
thought.  As noted by others, it is
less efficient than the static use case. In my mind, a bigger "gotcha" is
that to implement this I think you
almost have to create something like a variant data type.  This runs into
several issues that cause headaches
such as
1. Type safety.
2. What happens when you want to compare fields to a value or order them.
3. What happens when you want to assign from one variant to another.

At any rate, I feel that a careful specification of how row data is
represented in the dynamic case is important.

E.
The author writes that "parameter types, result types, etc. can be
retrieved from the driver after passing the
textual query/statement."  Sadly, no. When we wrote DTL on top of ODBC we
found that database vendors
often won't given you this information.
Places where this happens include:
1. Some vendors don't give information about the types returned at all.
2. Some have gaps, for example they may not tell you about the types
returned by a stored procedure.
3. Others have problems with special tables, e.g. the Linux ODBC driver for
SQL Server doesn't provide
catalog data for temporary tables like #MyTempTable.

F.
This brings us to catalog and field data.  A common request for any
database library is to be able to get a list
of tables and get information about fields in a table.  You have to have
some of this for the dynamic query case
so I think it is worth spelling out a catalog interface explicitly.

G.
The author writes: "For example the interface should not encourage (or even
allow for) accessing a query result
in an arbitrary order, as this restricts possible implementations."  I
strongly disagree.  While I think that
a random access iterator should be an optional interface, in certain cases
this is important to have. Many databases
go to significant lengths to provide "scrollable" cursors so that users can
page back and forth through results
or navigate in a random access fashion.  Correspondingly, some applications
need to be able to do this in an
efficient way (loading a whole table into a buffer doesn't cut it) so this
interface does serve a real purpose.
Here is a bit of background:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms710292(v=vs.85).aspx

H.
I'm not sure why the author thinks DTL doesn't support general SQL
statements or transactions.  In fact,
I'm proud of the way that DTL maps C++ exception safety to database
transaction safety to get ACID guarantees.
We thought about it very carefully and have a detailed write-up here:
http://dtemplatelib.sourceforge.net/ExceptionHandling.htm


G.
As explained above, the usual paradigm in DTL is to bind rows to a
particular struct and look at them via a container.
Optimizing for individual queries isn't our main goal but if we just wanted
to run a query with a
bound variable we would probably code it more compactly than the example in
the paper via:

DynamicDBView<> view("USERS", "name", "where id=?");
DynamicDBView<>::select_iterator sel_it = view.begin();
sel_it.Params()[0] = 1234;
for(;sel_it != view.end();++sel_it)
  cout << *sel_it << endl;

Note that we set the parameter on the iterator because our library
automatically "prepares" queries for execution
efficiency.

To take another example, here is a query to print all rows from a table
(from our library introduction at
http://dtemplatelib.sourceforge.net/dtl_introduction.htm)

DynamicDBView<> view("DB_EXAMPLE", "*");
copy(view.begin(), view.end(), ostream_iterator<variant_row>(cout, "\n"));

H.
In general, we feel that DTL is efficient and the library comes with
benchmarks versus raw ODBC that you can try
yourself.  A comparison versus raw ODBC can be seen here
(http://dtemplatelib.sourceforge.net/Performance.htm)
and the overhead is fairly modest.

I.
Databases typically have types which don't have direct analogs in C++ and
require some extra work.  Examples would include dates/times, BLOBs or long
strings which require special handling.  I think an interface specification
probably needs to say something about these types.  Also, NULL values are
possible and these need to be handled in some manner.








--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_445_8282894.1365658508233
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>As one of the authors of DTL I wanted to make a few comments here.</di=
v><div><br></div><div>A.</div><div>First, the specification laid out here i=
s very query-centric. &nbsp;In contrast, the goal of DTL is to avoid writin=
g</div><div>raw queries when we can. &nbsp;Instead, the idea of DTL is</div=
><div><br></div><div>1. Define a struct to hold row data.</div><div>2. Defi=
ne a mapping from fields in the struct to fields in a table. (An object-rel=
ational mapping or ORM).</div><div>3. Create a C++ standard compliant conta=
iner from the struct + ORM. &nbsp;Loop through the container to read rows,&=
nbsp;</div><div>assign to the container to update rows, add/remove from the=
 container to insert and delete rows.</div><div><br></div><div>In the DTL s=
etting using raw queries is the exception rather than the rule - although w=
e do have support for general queries.</div><div><br></div><div>There are s=
ome positive features to this design:</div><div><br></div><div>1. Using phy=
sical structs (we also support classes) is memory efficient and gives fast =
code. &nbsp;When you access a field via an</div><div>expression like Employ=
ee.Salary there is no overhead.</div><div>2. A container interface is a nat=
ural way to think about a table.</div><div>3. We were able to provide a cle=
an and concise syntax for mapping fields in a structure to fields in a tabl=
e.</div><div>This facilitates easy generation and maintenance of any databa=
se mappings.</div><div><br></div><div><br></div><div>B.</div><div>There are=
 other well known database libraries which provide a similar abstraction. O=
ne famous example that is well worth</div><div>examining is the Java Hibern=
ate library: http://en.wikipedia.org/wiki/Hibernate_(Java).</div><div><br><=
/div><div>C.&nbsp;</div><div>The code samples given by the author mostly se=
em to loop over the result set from a query. &nbsp;For example:</div><div>f=
or(auto row:query()) {</div><div>&nbsp; // do something with each row</div>=
<div>}</div><div><br></div><div>In the ODBC world there are at least two us=
age cases that cause problems for this model.</div><div>1. Stored procedure=
s can return multiple result sets.</div><div>2. For efficiency, bulk operat=
ions are important in ODBC. These can be over 100x faster than row-wise ope=
rations</div><div>and typically operate on an array of POD type data "all-a=
t-once".</div><div><br></div><div>D.&nbsp;</div><div>The dynamic use case g=
iven in the paper is important, but requires careful thought. &nbsp;As note=
d by others, it is</div><div>less efficient than the static use case. In my=
 mind, a bigger "gotcha" is that to implement this I think you</div><div>al=
most have to create something like a variant data type. &nbsp;This runs int=
o several issues that cause headaches</div><div>such as</div><div>1. Type s=
afety.</div><div>2. What happens when you want to compare fields to a value=
 or order them.</div><div>3. What happens when you want to assign from one =
variant to another.</div><div><br></div><div>At any rate, I feel that a car=
eful specification of how row data is represented in the dynamic case is im=
portant.</div><div><br></div><div>E.</div><div>The author writes that "para=
meter types, result types, etc. can be retrieved from the driver after pass=
ing the</div><div>textual query/statement." &nbsp;Sadly, no. When we wrote =
DTL on top of ODBC we found that database vendors&nbsp;</div><div>often won=
't given you this information.</div><div>Places where this happens include:=
</div><div>1. Some vendors don't give information about the types returned =
at all.</div><div>2. Some have gaps, for example they may not tell you abou=
t the types returned by a stored procedure.</div><div>3. Others have proble=
ms with special tables, e.g. the Linux ODBC driver for SQL Server doesn't p=
rovide</div><div>catalog data for temporary tables like #MyTempTable.</div>=
<div><br></div><div>F.</div><div>This brings us to catalog and field data. =
&nbsp;A common request for any database library is to be able to get a list=
</div><div>of tables and get information about fields in a table. &nbsp;You=
 have to have some of this for the dynamic query case</div><div>so I think =
it is worth spelling out a catalog interface explicitly.</div><div><br></di=
v><div>G.&nbsp;</div><div>The author writes: "For example the interface sho=
uld not encourage (or even allow for) accessing a query result</div><div>in=
 an arbitrary order, as this restricts possible implementations." &nbsp;I s=
trongly disagree. &nbsp;While I think that</div><div>a random access iterat=
or should be an optional interface, in certain cases this is important to h=
ave. Many databases</div><div>go to significant lengths to provide "scrolla=
ble" cursors so that users can page back and forth through results</div><di=
v>or navigate in a random access fashion. &nbsp;Correspondingly, some appli=
cations need to be able to do this in an</div><div>efficient way (loading a=
 whole table into a buffer doesn't cut it) so this interface does serve a r=
eal purpose.</div><div>Here is a bit of background: http://msdn.microsoft.c=
om/en-us/library/windows/desktop/ms710292(v=3Dvs.85).aspx</div><div><br></d=
iv><div>H.</div><div>I'm not sure why the author thinks DTL doesn't support=
 general SQL statements or transactions. &nbsp;In fact,</div><div>I'm proud=
 of the way that DTL maps C++ exception safety to database transaction safe=
ty to get ACID guarantees. &nbsp;</div><div>We thought about it very carefu=
lly and have a detailed write-up here: http://dtemplatelib.sourceforge.net/=
ExceptionHandling.htm</div><div><br></div><div><br></div><div>G.</div><div>=
As explained above, the usual paradigm in DTL is to bind rows to a particul=
ar struct and look at them via a container.</div><div>Optimizing for indivi=
dual queries isn't our main goal but if we just wanted to run a query with =
a&nbsp;</div><div>bound variable we would probably code it more compactly t=
han the example in the paper via:</div><div><br></div><div>DynamicDBView&lt=
;&gt; view("USERS", "name", "where id=3D?");</div><div>DynamicDBView&lt;&gt=
;::select_iterator sel_it =3D view.begin();</div><div>sel_it.Params()[0] =
=3D 1234;</div><div>for(;sel_it !=3D view.end();++sel_it)</div><div>&nbsp; =
cout &lt;&lt; *sel_it &lt;&lt; endl;</div><div><br></div><div>Note that we =
set the parameter on the iterator because our library automatically "prepar=
es" queries for execution</div><div>efficiency.</div><div><br></div><div>To=
 take another example, here is a query to print all rows from a table (from=
 our library introduction at&nbsp;</div><div>http://dtemplatelib.sourceforg=
e.net/dtl_introduction.htm)</div><div><br></div><div>DynamicDBView&lt;&gt; =
view("DB_EXAMPLE", "*");&nbsp;</div><div>copy(view.begin(), view.end(), ost=
ream_iterator&lt;variant_row&gt;(cout, "\n"));</div><div><br></div><div>H.<=
/div><div>In general, we feel that DTL is efficient and the library comes w=
ith benchmarks versus raw ODBC that you can try</div><div>yourself. &nbsp;A=
 comparison versus raw ODBC can be seen here (http://dtemplatelib.sourcefor=
ge.net/Performance.htm)</div><div>and the overhead is fairly modest.</div><=
div><br></div><div>I.</div><div>Databases typically have types which don't =
have direct analogs in C++ and require some extra work. &nbsp;Examples woul=
d include dates/times, BLOBs or long strings which require special handling=
.. &nbsp;I think an interface specification probably needs to say something =
about these types. &nbsp;Also, NULL values are possible and these need to b=
e handled in some manner.</div><div><br></div><div><br></div><div><br></div=
><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div=
>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_445_8282894.1365658508233--

.


Author: Beman Dawes <bdawes@acm.org>
Date: Sat, 13 Apr 2013 16:45:08 -0400
Raw View
On Tue, Apr 2, 2013 at 9:10 AM,  <tortoise741@gmail.com> wrote:
> Hi all,
>
> With regards to "N3612: Desiderata of a C++11 Database Interface",
> the paper provides a useful review of several existing libraries...

The C++ committee is currently tabling database related papers because
we don't have enough participants who are willing to work on database
issues. If you are interested, consider participating. The committee
depends on volunteers, so if no one volunteers to work on something,
it doesn't happen.

--Beman

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.


Author: jl@yorel.be
Date: Mon, 22 Apr 2013 12:32:37 -0700 (PDT)
Raw View
------=_Part_2501_27884376.1366659157112
Content-Type: text/plain; charset=ISO-8859-1

For what it's worth, a few years ago I worked on a tentative Boost RDB
library. It is not considered in your paper, but it may be worth a look.
You can find the tutorial here:
http://www.yorel.be/boost/libs/rdb/doc/html/rdb/tutorial.html

My real interest in fact object-relational mapping. I built one such tool
on top of Rogue Wave's library DBTools++ around 1997. Because of the lack
of a Boost database binding, I was side-tracked into implementing one. I
dropped the project for a series of reasons.

The major characteristic of the library is that it integrates tightly in
the C++ static type system. The table declaration mechanism is inspired by
Matus Chochlik's Mirror library.

Jean-Louis

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_2501_27884376.1366659157112
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

For what it's worth, a few years ago I worked on a tentative Boost RDB libr=
ary. It is not considered in your paper, but it may be worth a look. You ca=
n find the tutorial here:&nbsp;<a href=3D"http://www.yorel.be/boost/libs/rd=
b/doc/html/rdb/tutorial.html">http://www.yorel.be/boost/libs/rdb/doc/html/r=
db/tutorial.html</a><div><br></div><div>My real interest in fact object-rel=
ational mapping. I built one such tool on top of Rogue Wave's library DBToo=
ls++ around 1997. Because of the lack of a Boost database binding, I was si=
de-tracked into implementing one. I dropped the project for a series of rea=
sons.</div><div><br></div><div>The major characteristic of the library is t=
hat it integrates tightly in the C++ static type system. The table declarat=
ion mechanism is inspired by Matus Chochlik's Mirror library.</div><div><br=
></div><div>Jean-Louis</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2501_27884376.1366659157112--

.


Author: =?UTF-8?Q?Mateusz_=C5=81oskot?= <mateusz@loskot.net>
Date: Wed, 25 Sep 2013 06:17:22 -0700 (PDT)
Raw View
------=_Part_5338_11849956.1380115042338
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I'd like to follow up to this archived thread with question related to the
"1.3 Seamless Integration in C++" section, which states:

"""
The libsoci code is quite readable, but the usage of overloaded comma
operators is
a bit unusual. In addition, libsoci plays games with the lifetime of
temporary objects
to detect the end of the statement (i.e., the last comma-separated value).
These brittle
tricks would not be necessary in C++11 when using variadic template
functions.
"""

I would like to learn about details of the variadics-based solution Thomas
proposed.
Thomas, or anyone, what are the actual options here?

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

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_5338_11849956.1380115042338
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>I'd like to follow up to=
 this archived thread with question related to the "1.3 Seamless Integratio=
n in C++" section, which states:</div><div><br></div><div>"""</div><div>The=
 libsoci code is quite readable, but the usage of overloaded comma operator=
s is</div><div>a bit unusual. In addition, libsoci plays games with the lif=
etime of temporary objects</div><div>to detect the end of the statement (i.=
e., the last comma-separated value). These brittle</div><div>tricks would n=
ot be necessary in C++11 when using variadic template functions.</div><div>=
"""</div><div><br></div><div>I would like to learn about details of the var=
iadics-based solution Thomas proposed.</div><div>Thomas, or anyone, what ar=
e the actual options here?</div><div><br></div><div>Best regards,</div><div=
>--&nbsp;</div><div>Mateusz Loskot, http://mateusz.loskot.net</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5338_11849956.1380115042338--

.


Author: Mateusz Loskot <mateusz@loskot.net>
Date: Wed, 25 Sep 2013 15:14:56 +0100
Raw View
On 25 September 2013 14:29, Jean-Louis Leroy <jl@yorel.be> wrote:
>
> Circa 2009 I worked on a type safe approach to database binding - see here:
> https://code.google.com/p/boost-rdb/ and the doc here
> http://www.yorel.be/boost/libs/rdb/doc/html/

Jean-Louis,

I've been looking at your project for long time now, as well as std::rdb,
Boost.SQL and other initiatives discussed here and there.

> I am now thinking of reviving the project in a C++11 form, while dropping
> some rather extreme design decisions (each column its own type). It seems to
> me that a statically typed interface (with optional type erasure) would be a
> more C++ish way of doing things. I have requested permission from my
> employer to work on this as an open source project. I am confident that I
> will obtain it soon. In that case, I would be happy to take part in the
> discussion.

I'm the current maintainer of SOCI project, I've taken over the broom
from Maciej Sobczak.
In SOCI, there is no plan to switch/port to C++11 as it actually would
mean writing a new library, no doubt.
But, there is room for some improvements or additions related to C++11 features.

I'm personally interested in future post-C++11 initiatives related to
database abstraction,
to discuss new options, and to learn about new ideas.
SOCI experience could be helpful here too.

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

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.


Author: Jean-Louis Leroy <jl@yorel.be>
Date: Wed, 25 Sep 2013 14:29:50 +0100
Raw View
Hello,

Circa 2009 I worked on a type safe approach to database binding - see=20
here: https://code.google.com/p/boost-rdb/ and the doc here=20
http://www.yorel.be/boost/libs/rdb/doc/html/

It was before variadic templates were available, so I had to do a lot of=20
meta-programming (I relied on Boost.Fusion) and in the end my compiler=20
slowed to a crawl. I gave up in disgust.

I am now thinking of reviving the project in a C++11 form, while=20
dropping some rather extreme design decisions (each column its own=20
type). It seems to me that a statically typed interface (with optional=20
type erasure) would be a more C++ish way of doing things. I have=20
requested permission from my employer to work on this as an open source=20
project. I am confident that I will obtain it soon. In that case, I=20
would be happy to take part in the discussion.

Regards,
Jean-Louis Leroy

On 25-Sep-13 14:17, Mateusz =C5=81oskot wrote:
> Hi,
>
> I'd like to follow up to this archived thread with question related to=20
> the "1.3 Seamless Integration in C++" section, which states:
>
> """
> The libsoci code is quite readable, but the usage of overloaded comma=20
> operators is
> a bit unusual. In addition, libsoci plays games with the lifetime of=20
> temporary objects
> to detect the end of the statement (i.e., the last comma-separated=20
> value). These brittle
> tricks would not be necessary in C++11 when using variadic template=20
> functions.
> """
>
> I would like to learn about details of the variadics-based solution=20
> Thomas proposed.
> Thomas, or anyone, what are the actual options here?
>
> Best regards,
> --=20
> Mateusz Loskot, http://mateusz.loskot.net
> --=20
>
> ---
> You received this message because you are subscribed to a topic in the=20
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit=20
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/iqOtgxP_IRA/=
unsubscribe.
> To unsubscribe from this group and all its topics, send an email to=20
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.


Author: rbock@eudoxos.de
Date: Sun, 10 Nov 2013 12:21:35 -0800 (PST)
Raw View
------=_Part_309_12715212.1384114895833
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, September 25, 2013 3:29:50 PM UTC+2, Jean-Louis Leroy wrote:
>
> Hello,
>
> Circa 2009 I worked on a type safe approach to database binding - see
> here: https://code.google.com/p/boost-rdb/ and the doc here
> http://www.yorel.be/boost/libs/rdb/doc/html/
>
> It was before variadic templates were available, so I had to do a lot of
> meta-programming (I relied on Boost.Fusion) and in the end my compiler
> slowed to a crawl. I gave up in disgust.
>

I had a similar experience in 2010...


>
> I am now thinking of reviving the project in a C++11 form, while
> dropping some rather extreme design decisions (each column its own
> type). It seems to me that a statically typed interface (with optional
> type erasure) would be a more C++ish way of doing things. I have
> requested permission from my employer to work on this as an open source
> project. I am confident that I will obtain it soon. In that case, I
> would be happy to take part in the discussion.
>

My current result of starting from scratch with C++11 can be seen here:

https://github.com/rbock/sqlpp11

As far as I can tell, the ideas are pretty similar, although I stuck with
each column having it's own type. This actually helps a lot to get
type-safe results, where each field of a row is represented as an
accurately named member of the row (in the static case). Thus, there is no
need to access fields with positional arguments.

Even aliases have their own types for this reason.


To pick up on some of the themes in this thread:

   - As the name implies, the library currently targets SQL.
   - It offers embedded, strongly typed language support for SQL in C++.
   - It has no concrete database connection of its own, but requires
   certain traits in a database connector library. At the time of this writing
   there are connector libraries for MySQL and Sqlite3. sqlpp11 itself
   therefore does not care about TCP or Unix sockets, connection pools or
   multi-threaded access.
   - I haven't really thought about extending it to other data sources like
   XML or JSON, but I guess that it would just require a different instance of
   a connector library.
   - It is query centric. It supports joins and sub-selects, etc because we
   need this when operating on relational databases.
   - It assumes that the developer knows which tables to operate on at
   compile time. Methods to check at runtime whether the compile time
   information about table structures was accurate would be helpful, of
   course, but are not present yet.
   - It favors static query structures but allows dynamic parts as well,
   where needed.
   - Result rows are accessed strictly in sequential order, use limit and
   offset for paging.
   - Fields of a row are accessed as appropriately typed member variables
   of a the row object. There is no overhead in name or position lookup.
   - The library aims for small memory and runtime overhead, lots of
   compile time checks, reasonable compile error messages, developer-friendly
   compile times and a small list of dependencies (none except a decent
   compiler and a matching STL at the moment).


Cheers,

Roland

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_309_12715212.1384114895833
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, September 25, 2013 3:29:50 PM UTC+2,=
 Jean-Louis Leroy wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hello,
<br>
<br>Circa 2009 I worked on a type safe approach to database binding - see=
=20
<br>here: <a href=3D"https://code.google.com/p/boost-rdb/" target=3D"_blank=
">https://code.google.com/p/<wbr>boost-rdb/</a> and the doc here=20
<br><a href=3D"http://www.yorel.be/boost/libs/rdb/doc/html/" target=3D"_bla=
nk">http://www.yorel.be/boost/<wbr>libs/rdb/doc/html/</a>
<br>
<br>It was before variadic templates were available, so I had to do a lot o=
f=20
<br>meta-programming (I relied on Boost.Fusion) and in the end my compiler=
=20
<br>slowed to a crawl. I gave up in disgust.
<br></blockquote><div><br>I had a similar experience in 2010...<br>&nbsp;</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>I am now thinking of reviving the project in a C++11 form, while=20
<br>dropping some rather extreme design decisions (each column its own=20
<br>type). It seems to me that a statically typed interface (with optional=
=20
<br>type erasure) would be a more C++ish way of doing things. I have=20
<br>requested permission from my employer to work on this as an open source=
=20
<br>project. I am confident that I will obtain it soon. In that case, I=20
<br>would be happy to take part in the discussion.
<br></blockquote><div><br>My current result of starting from scratch with C=
++11 can be seen here:<br></div><div><br><a href=3D"https://github.com/rboc=
k/sqlpp11">https://github.com/rbock/sqlpp11</a><br><br>As
 far as I can tell, the ideas are pretty similar, although I stuck with=20
each column having it's own type. This actually helps a lot to get=20
type-safe results, where each field of a row is represented as an=20
accurately named member of the row (in the static case). Thus, there is=20
no need to access fields with positional arguments. <br><br>Even aliases ha=
ve their own types for this reason.<br><br><br>To pick up on some of the th=
emes in this thread:<br><ul><li>As
 the name implies, the library currently targets SQL.</li><li>It offers emb=
edded,
 strongly typed language support for SQL in C++.</li><li>It has no concrete=
 database connection of its own, but requires certain traits in a database =
connector library. At the time of this writing there are connector librarie=
s for MySQL and Sqlite3. sqlpp11 itself therefore does not care about TCP o=
r Unix sockets, connection pools or multi-threaded access.<br></li><li>I ha=
ven't really thought about extending it to other data sources like XML or J=
SON, but I guess that it would just require a different instance of a conne=
ctor library.</li><li>It is query centric. It supports joins and sub-select=
s, etc because we need this when operating on relational databases.</li><li=
>It assumes that the developer knows which tables to operate on at compile =
time. Methods to check at runtime whether the compile time information abou=
t table structures was accurate would be helpful, of course, but are not pr=
esent yet.<br></li><li>It favors static query=20
structures but allows dynamic parts as well, where needed.</li><li>Result r=
ows are accessed strictly in sequential order, use limit and offset for pag=
ing.</li><li>Fields of a row are accessed as appropriately typed member var=
iables of a the row object. There is no overhead in name or position lookup=
..</li><li>The library aims for small memory and runtime overhead, lots of c=
ompile time checks, reasonable compile error messages, developer-friendly c=
ompile times and a small list of dependencies (none except a decent compile=
r and a matching STL at the moment).</li></ul><p></p><br>Cheers,<br><br>Rol=
and<br><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_309_12715212.1384114895833--

.