Conversion of a SQL model into a standard item model?

[elfring]

The development of SQL data models can be useful for some software applications. Some applications might prefer to work still with a standard item model for a while instead.

How often do you see the need to convert database information into the other programming interface by corresponding proxy model classes?

[VRonin]

@elfring said in Conversion of a SQL model into a standard item model?:

Some applications might prefer to work still with a standard item model for a while instead

May I ask why?

[elfring]

May I ask why?

• Possible change resistance
• Unclear development efforts (and additional dependencies) for a software transformation to better SQL data models

[VRonin]

@elfring said in Conversion of a SQL model into a standard item model?:

Possible change resistance

Deal with it.
If you mean change in code, by only interacting with QStandardItemModel via the QAbstractItemModel interface as I always suggest, makes changing the model a matter of 1 code line

Unclear development efforts (and additional dependencies)

The additional dependency is the SQL module. Hard to get around it if you want to interact with an SQL database

[elfring]

… if you want to interact with an SQL database

Unfortunately, the Qt software documentation mentions specific limitations for the class “QSqlTableModel” so far.

[SGaist]

Do you mean the ones solved by QSqlRelationalTableModel and QSqlRelationalDelegate mentioned in the documentation you are linking to ?

[elfring]

Maybe.

Do both table model classes share still the main restriction on editing from a single database table?

[SGaist]

It's not a restriction, it's how the class works. QSqlTableModel as it name suggest allows access to one table.

So what exactly are you after ?
Specify a real situation
Specify a real need

[elfring]

QSqlTableModel as it name suggest allows access to one table.

Can such classes collaborate also with database views?

[VRonin]

From the article you linked:

If the database system can determine the reverse mapping from the view schema to the schema of the underlying base tables, then the view is updatable. INSERT, UPDATE, and DELETE operations can be performed on updatable views.

Since there's no generic way for a Qt model to know that, it is left to the user to implement using QSqlQuery directly

[elfring]

Would it be nicer if a table model can determine if it is based on an updatable view?

[VRonin]

Yes, but once again

@VRonin said in Conversion of a SQL model into a standard item model?:

there's no generic way for a Qt model to know that

[elfring]

Do full-featured standard item models become a bit more attractive then?

[SGaist]

Attractive for what ?

[elfring]

Would you like to compare the attractiveness of the mentioned data model variants any further?

[SGaist]

I'll let you start by providing the analysis you want to discuss about.

[elfring]

Is there a “development competition” going on between data processing by SQL queries and/or Qt standard items?

[JKSH]

@elfring said in Conversion of a SQL model into a standard item model?:

Is there a “development competition” going on between data processing by SQL queries and/or Qt standard items?

No, there is no competition going on.

@elfring, what is your goal for asking us these questions? Are you trying to get us to write a "software extension" for you?

[elfring]

I hope that more software evolution can happen in this area so that the switching between discussed data models might become easier.

[JKSH]

@elfring said in Conversion of a SQL model into a standard item model?:

I hope that more software evolution can happen in this area so that the switching between discussed data models might become easier.

We will not perform this "software evolution" because we cannot see any good reason to provide additional conversion/switching between QSqlTableModel and QStandardItemModel. Furthermore, none of your posts above provide convincing arguments for this conversion/switching.