lifespan of QSqlRecord?

[RolandHughes]

All,

Quick question before I go down a coding bunny hole. Does anyone here know what the lifespan of a QSqlRecord is? This gives me pause:

http://qt-project.org/doc/qt-4.8/qsq...ml#operator-eq
QSqlRecord is implicitly shared. This means you can make copies of a record in constant time.

I'm asking because I find myself in a situation where I need to pass in convoluted where clause strings to dynamically build an ugly SELECT which uses multiple LEFT JOIN SELECTS. (Don't ask. I was unable to successfully champion the idea of organizing the database the way it is actually needed vs. the way which takes up the smallest amount of storage.) The database access is in its own thread so the GUI never locks because of it. No problems there. What I've never done though is build a vector of QSqlRecord and return it (or reference to it).

Does anyone know if a deep copy happens when the finish() is executed for the query or the commit() happens or the thread disconnects from database? An implicit share to something which doesn't "legally" exist anymore will cause random crashes, so, before I head down that path and burn a lot of time . . . anyone know the answer off top of their head?

[wysota]

QSqlRecord is strictly a data carrier class. It lives as long as its object lives. It has no lifespan relation to any of the database objects (QSqlDatabase or QSqlQuery).

[RolandHughes]

So, if I interpret your statement correctly, it is just like QString? The "implicitly shared" phrase made it sound like

QSqlRecord r = q.record();
vector.append(r);

would leave a ghost inside of the vector.

Thanks, I will code it up and give it a try.

[wysota]

So, if I interpret your statement correctly, it is just like QString?

Yes.

The "implicitly shared" phrase made it sound like

QSqlRecord r = q.record();
vector.append(r);

would leave a ghost inside of the vector.

No, because append() makes a shallow copy of r. Exactly as QString, QColor or almost all other value classes in Qt.