[Development] On QML and keeping data alive.

Charley Bay charleyb123 at gmail.com
Thu Aug 15 17:51:17 CEST 2013

Rene wrote:

> Hi Qt developers
> A little over a year ago I raised a question on this list about
> QSharedPointers and QML, and got a lot of debate started, which turned out
> to be very illuminating. (
> http://lists.qt-project.org/pipermail/development/2012-May/004049.html)

> <snip, now clarifying deeper problems, how QML fits in MVC>

> <snip>, Clearly I am talking about the difficulties of a database
> application.<snip>,
The key is that SHARED OWNERSHIP must take effect during the use of the
> objects in question.
> <snip>,
> Now the punch line...
> ===========================
> While I see is as the job of the model to query the database and serialize
> the SQL response into Q_PROPERTIES, I am quite reluctant to wish that
> objects in the model domain should store QSharedPointers and hence be
> responsible for resources being locked in memory as long as their (shared)
> parent keeps them stored.
> Instead I see it as the job of the View/Controller to lay claim to
> resources while they are in use. Why? Because the controller ultimately is
> responsible for actually using the database resource for as long as the
> view exists.
> So far I have surprised very few programmers. The MODEL queries and
> serializes data and the CONTROLLER does the resource management deciding
> when it is time to let go of database resources again.

Agreed.  IMHO, this is the only significant "design issue" we've run into
with using the QAIM (and there have been discussions on this list in the
past, I can look them up if anyone cares).

A change-to-the-design with this consideration (where the "view" secures
transient resources from the "model") could be done in a number of ways, I
think.  But, I think it's important.

> <snip>,
> ===========================
> By now I think you get the problem (and sorry for being overly verbose).
> QtQuick items makes good views but bad controllers. QWidget based forms are
> fairly good for both. <snip>,

Mostly agree, although I also have issues with QWidget-QAIM, in that I want
the "QModelIndex" to have "type-information" OR wholly-contain state, such
as a QSharedPointer<>.

<snip, ASCII art, lifetime of database resources and objects>

> But that still leaves out difficult decisions. Continuing on our example,
> let's see how a simple CompanyView.qml could work out, using typical QML
> idioms:
> Item {
>     property Company company
>     Column {
>         Text { text: company.name; .... }
>         ListView {
>             model: company.employees <<<<<<<<< PROBLEM: What does this
> mean?
>             ....
>         }
>     }
> }
> Text {
>     property Person person
>     text: person.name
> }
> Look at the place where the ListView is bound to the companys employee
> list. What exactly is being asked of the model here? The semantics are
> unclear. Is QML asking the C++ model to load the employees and then forget
> about the references? I.e. can the C++ model trust the controller to keep
> and store references itself? Clearly the view is accessing the model
> directly, and that leaves out the controller, which should have helped
> store the reference in a guaranteed way.
> In all fairness, the problem would also exist in a QWidget scenario. But
> QML is extra difficult, because MVC usage patterns in my opinion aren't
> really clear yet. My current instinct commands that me to make the most
> beautiful interface, i.e. one using QQuickListProperty, which is not very
> intuitive when it comes to custom types, and doesn't give a lot of room for
> dealing with the resource management situation.
> Just like last year, I wish for an enriching debate, hoping I have
> demonstrated the need to think usage patterns into the API design.
> Best regards,
> Rene Jensen
> P.S.: You can always design your way out of most problems, and in this
> case I will probably end up doing just that. But I still wish to hear your
> take on the problem, because I imagine that these issues have been solved
> before.

IMHO, this is a tricky problem, that is not just QAIM/MVC.  Specifically, I
think we're talking about "value-semantics" and "reference-semantics" for
instances that bridge across the QML/C++ boundary.  Of course, as Rene
points out, this is a "screamingly-loud-issue" when it comes to database
resources, which is the thrust of his post.

In this case, "value-semantics" in the view ensure the database
resources/objects can be released (and still be represented in the "view"),
while "reference-semantics" in the view ensure the database
resources/objects must persist (in-memory).

I don't have specific suggestions (yet) on what to do.  However, we have
similar issues related to our "data-models" that bridge QML/C++, and even
for other "many-to-many" instances that bridge the QML/C++ boundary (which
comes up a lot in our designs when interfacing directly with

My "wimpy" suggestion that I made in the past:  I want "QModelIndex" to
have additional "type-information" that identifies my application-specific
types, OR the ability to wholly contain a QSharedPointer-type thing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130815/bb22a659/attachment.html>

More information about the Development mailing list