[Qt-interest] Qt5 and SQL

[Till Oliver Knoll]

Am 06.06.11 23:00, schrieb Jason H:
> ...
> But I am thinking session=connection, as I don't know any multi-session
> connections or multi-connection sessions.

They in fact exist ;)

Quoting from my 5 kg "Expert Oracle Database Architecture" handbook I am
about to read, chapter "Connections vs. Sessions":

"It surprises many people to discover that a connection is not
synonymous with a session. [...] A connection may have zero, one or more
sessions established on it. Each session is separate and independent,
even though they all share the same physical connection to the database.
A commit in one session does not affect any other session in that
connection. [...]
  In Oracle, a connection is simply a physical circuit between your
client process and the database instance - a network connection, most
commonly. [...] Session: A session is a logical entity that exists in
the instance. [...] It is your session on the server, where you execute
SQL, commit transactions, and run stored procedures."

And example where a given connection has TWO sessions is when you turn
on AUTOTRACE (the Oracle SQL command: "set autotrace on statistics"). In
one session your actual SQL to trace is being executed, the other trace
session is generated by Oracle for you.


For the on-topic question: QDatabase is indeed a bit awkward, it is
really the connection where you issue the SQL commands, which are then
passed to the driver, which then passes it to the database (whether that
DB is an "embedded one" such as SQLite doesn't matter for the sake of
argument).

If one really wanted to expand the Qt SQL classes I would opt for a
solution close (or even copying, with the usual Qt naming patterns) to JDBC:

- Having a Driver Manager (or better: DataSource)
- Having a Connection
- Having a Statement
- etc.

See well-known API e.g. here:

http://download.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html

The advantage would be to establish a "well-known database API pattern",
and people coming from Hibernate would feel "more familiar" with the Qt
API, and hence it would hopefully easier to "port" such frameworks.

The same would off course apply to (future/existing) DB drivers maybe...
(I am not a JDBC expert at all though, I just know it from daily usage,
and much more from a "persistence framework point-of-view" like Hibernate).


Other than that argueing whether QDatabase should be simply renamed to
QConnection are rather pointless, IMHO.


Cheers, Oliver