[Qt-interest] Qt5 and SQL

[Jason H]

I take issue with some of that. Queries are executed in sessions, which are connections. For instance On SQL SERVER #prefixed tables are active for a session, which is a connection. In Oracle, transactions happen in your session until they are committed. If you update a table in your session and query it you'll see your changes. Query it from another session, and you won't see them. Call commit() and they will show up.

So We have databases which have either connections or sessions, and transactions which are one or more queries. I think connections and sessions are the same - they are a view of the database with their own resources. I'm sure vendor implementations will vary. A session is usually a connection, with your own view of database objects. Your view may not be the same as others, until your transaction is committed. You might have resources (temporary tables) that are only viewable by you in your session.

But I am thinking session=connection, as I don't know any multi-session connections or multi-connection sessions. 

A database generally is a protocol driver and collection of sessions/connections and database objects.






________________________________
From: Constantin Makshin <cmakshin at gmail.com>
To: Qt Interest <qt-interest at qt.nokia.com>
Sent: Monday, June 6, 2011 3:48 PM
Subject: Re: [Qt-interest] Qt5 and SQL

IMHO, this isn't so obvious. For example, exec(), primaryIndex(), record(), transaction(), commit(), rollback() and tables() methods will look [a bit] weird in a class named QSqlConnection:
1) queries are executed on the database and not on connection;
2) index is part of the database, not connection;
3) database, not connection, has records;
4) transactions make little sense in the context of connections (who *really* cares about guaranteed network packet delivery if the underlying DBMS doesn't guarantee its consistency?);
5) connection doesn't have any tables, the database does.

Also, the "connection" word itself doesn't fit the concept of embedded DBMSes like SQLite very well.

I'm not sure "QSqlConnection" name will be [significantly] less confusing than "QSqlDatabase" — the class has both connection- and database-related functions/methods. And splitting it into 2 separate classes ("QSqlConnection" with only connection-related methods like connectOptions(), hostName() and others; "QSqlDatabase" with only database-related functions like ones mentioned above) can make things look even worse.

On Monday 06 June 2011 20:26:33 Jason H wrote:
> Well, it is and isn't a database.
> 
> You still have to call QSqlDatabase::addDatabase(...)  which initializes the driver for a database.
> But I agree, everything else should be using a QSqlConnection class.
> 
> 
> 
> 
> ________________________________
> From: Alan Ezust <alan.ezust at gmail.com>
> To: Ed Smith-Rowland <3dw4rd at verizon.net>
> Cc: qt-interest at qt.nokia.com
> Sent: Monday, June 6, 2011 11:47 AM
> Subject: Re: [Qt-interest] Qt5 and SQL
> 
> I see the QtSql module as a nice start for a database independent way
> of accessing databases.
> But the first thing I stumbled on when I was learning it and also when
> teaching it to others is the confusing name given to this class:
> "QSqlDatabase".
> 
> it does not represent a database. It is a connection.
> 
> Shouldn't someone start the process of renaming it to QSqlConnection,
> having a deprecated typedef to QSqlDatabase in Qt5, so that we can
> remove QSqlDatabase from Qt6?
> 
> And also, I was wondering if anyone has any experience playing around with
> this other hibernatish object-relational mapping layer?
>        http://www.codesynthesis.com/products/odb/
> >From what I can see, it doesn't use Qt to access the database, and it
> works on MySQL and SQLite.

_______________________________________________
Qt-interest mailing list
Qt-interest at qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110606/fed73ff2/attachment.html