{ |
int a; |
sql
object
encapsulates the session,std::string
variable,a
will receive the result.
sql.exec("select a, b, c from some_table"); |
sql.exec("select a, b from some_table"); // only TWO columns |
operator<<
provides a bad abstraction for the "input"
statements.operator<<
in the basic SOCI syntax
shows that something (the query) is sent somewhere (to the server).
Some people don't like this, especially when the "select" statements
are involved. If the high-level idea is to read data from somewhere, then operator<<
seems unintuitive to the die-hard IOStreams users. The fact is,
however, that the code containing SQL statement already indicates
that there is a client-server relationship with some other software
component (very likely remote). In such code it does not make any sense
to pretend that the communication is one-way only, because it's clear
that even the "select" statements need to be sent somewhere. This approach is
also more uniform and allows to cover other statements like "drop
table" or alike, where no data is expected to be exchanged at all (and
therefore the IOStreams analogies for data exchange have no sense at
all). No matter what is the kind of the SQL statement, it is sent to the server and this
"sending" justifies the choice of operator<<
.operator>>
and operator<<
)
as a way of distinguishing between different high-level ideas (reading and writing from the data store,
respectively) does make sense on much higher level of abstraction,
where the SQL statement itself is already hidden - and we do encourage
programmers to use SOCI for implementing such high-level abstractions.
For this, the object-relational mapping facilities available in SOCI
might prove to be a valuable tool as well, as an effective bridge
between the low-level world of SQL statements and the high-level world
of user-defined abstract data types.Previous (Backends reference) |