Graphics Scene data connect to SQL data

[Narada]

There is an application distributed with QT called "diagramscene". The user creates objects and connects them with arrows on a QGraphicsView. I would like to save this data to an SQL database using QSQLRelationalTable. Two tables are needed, one for the list of objects and the second for the list of connections. What does it take to allow the user to retrieve and save data using a QSQLRelationalModel? How do you connect the QGraphicsScene to QSQLRelationalModel?

[JonB]

@Narada
QSqlRelationalTableModel class provides an editable data model for a single database table, with foreign key support. It just wraps a QSqlTableModel which has one column whose values are in another table to display the second table's values when editing the first table's column. It is not relevant to your requirement. There is also no connection between a QGrapchicsScene and a QSqlTableModel.

You could write code to model the diagram with tables for objects and for connections for the purpose of saving if you wish, but it won't be to do with QSqlRelationalTableModel. You will want to allow a many-to-many (or at least many-to-2) relationship.

[Narada]

@JonB
Thanks for the response. It seems like a custom solution may be needed. In Qt designer, form designer and state chart designer the graphical information is saved in XML data. Tree views display additional data. So, there has to be a way to connect graphics objects to a data model even if it is a custom model. After that another layer must be developed to store and retrieve data from sql tables. I was looking for an existing set of classes to leverage on.

[JonB]

@Narada
I suspect https://stackoverflow.com/questions/13801114/qt-qgraphicsscene-and-qabstractitemmodel is still current. Worth a read.

[SGaist]

Hi,

I can see two different approaches:

1. the database is a state snapshot of your scene
2. your scene is a "view" on top of the database

With the former, you load the data at application startup and save it when quitting.

With the latter, you update the database when something changes in your scene so the database always reflects what is shown.

You might want to start with the former so you will have the basics working and then add the latter.

[Narada]

@SGaist
Yes, What you are suggesting is true for a single user single view application where the model is only communicating with one view. I agree it is a good starting point. An example of this is the "pagedesigner1" in "Advanced Qt Programming : Creating Great Software with C++and Qt4 " book by Mark Summerfield.

What if there are multiple views involved by a single user or if multiple users are involved with multiple views?. Then, a common model is needed to communicate with all the views to a single source of data such as an SQL database.

At this point I am only interested in understanding the architecture solution of the problem. What is the best chain of classes involved for a Model/View/Delegate solution for such a problem?

[JonB]

@Narada What is the issue about (possibly multiple) QGraphicsViews of you have the QGraphicsScene tied to the SQL database?

[Narada]

@JonB
Hi Jon,
I am just not clear (confident) about the chain of classes(base classes shown below).
Here is one option I assume. Let's start with Read Only for a single user case.

Is this chain (My first cut) correct?

The next steps would be to add Read/Write capability by adding delegates, and then expand the design to multi-user case.

[JonB]

@Narada
Like I said at the start, I don't see any relevance of QSqlRelationalTableModel here. And what it does it not terribly significant anyway. Nor do I know why it contributes the the QGraphicsScene while the others go into a QTreeModel. But perhaps you do. Other than that the diagram looks pretty :) Maybe others will follow better than I.

[Narada]

@JonB
Let's take the above diagram itself. This diagram is very much like the diagram I want to draw.

It has a set of boxes connected by arrows.

Now if we want to save this information in a relational database, we need to break it down to data tables. The data tables will consist of two tables; A list of boxes and a list of connections.
Table 1:

1. Box1
2. Box2
   .

Table 2:

1. Line1, From Box1, To Box2
2. Line2, From Box3, To Box4
   etc.

The list of connections in Table 2 need to refer to the list of boxes to store the connection information. That is where the relational table model comes in. It will combine Table 1 and Table 2 and compile the data into one.

The Tree Model is to display Some boxes containing other boxes recursively. That was drawn to show that multiple views will access the same data through different models.