qSqlRelationalTablemodel index question...

[scott_hollen]

A question for all you experts...

While debugging the addition of rows to a filtered relational table model, I was suprised to notice that the index() was filtered as well -- a rowcount() returned the number of rows in the filtered data, not the entire model. I guess this makes sense, but is it possible to add a row to my model that is *outside* of this filter? For instance, if my model contains all athletes at a University but I'm viewing a filtered list of only Baseball players, is it possible to insert a row that's a *copy* of a baseball player and change his key to, say, Football, since we found out he plays both? I need him to show up in my model under the Baseball and Football filter after I've copied the Baseball record.

How does this affect my indices?

Thanks!

scott

[wysota]

You can access the underlying model directly. You don't need to go through the proxy.

[scott_hollen]

Hmmm...If I've already executed a model->setFilter() command, and I'm only seeing the indices of the filtered, so how do I skirt that? How do I, in effect, rollback the filter? Either way, my goal is to find the row where key=BASEBALL and player=SCOTT, and copy that to a new row but make key=FOOTBALL...

in case you're wondering, I've got two projects going on at the same time doing similar things...One, I'm hoping to use to assist me in my day job and one in a 2nd job...

thanks!!!!

scott

[wysota]

Don't use setFilter. Use QSortFilterProxyModel. Otherwise the model contains only those rows from the database that conform to the filter. Unless of course that's what you want.

[scott_hollen]

DING DING DING! I believe you just nailed my issue -- I didn't realize that the filter did that, so I'll make that switch tonight!

thanks!

Scott

[wysota]

The filter is simply the WHERE clause of a SELECT statement issued to the database when creating the model.

[scott_hollen]

That makes a lot of sense to me now -- yea, I'm a newbie...I thought the filter was between the model and view which is why I was I was assuming if I just copied the data I needed and changed the field I was filtering on I would be fine, but when I'd click on my new master record, there would be nothing displayed...

The light's now on above my head, and I really appreciate it...
(for what it's worth, learning PL/SQL on my own 13 years ago was a lot easier than Qt's turning out to be, that's for sure!)


scott

[wysota]

Well... it's hard to compare the complexity of the two technologies

[scott_hollen]

Classes can equate to Packages and Package bodies, but that's about it! Actually the little bit of OOP I did was in Ada and PL/SQL is a subset of that, which is what aided me in learning it...

Theoretical question -- given the following:

1) Relatively small DB application with a well-designed database, with a properly normalized structure consisting of parent/child, or, master/detail tables
2) No more than 20 tables tops with a small number of rows (at most a couple hundred rows in the largest of the 5 or 6 detail tables)

In a well designed app, to reduce redundancy and save disk space, databases are normalized, but would it make sense with a small application to simplify things, namely the model/view design -- to normalize some data? In the project I'm working on, my detail table will probably never have any more than 50 or so records and the detail table, jeez, no more than say 500...Instead of creating 2 tableviews, 2 SQL models (one for master, one for detail), a QSortFilterProxyModel and managing the relation, would it maybe make sense to just add a column to my detail table and eliminate the master table altogether and apply the QSortFilterProxyModel there? That totally goes against my perfectionist nature, but given time constraints and my inexperience, wouldn't it simplify the implementation by taking me down to one view and 2 models?

Just something I'm thinking about as I'm struggling to figure out where to apply the QSortFilterProxyModel (one example I found applies it to the master, another to the detail -- oooof)

(Sorry to be so full of questions -- I'm reticent to post by nature but I'm working 50 hours a week on one job, doing this project for my father-in-law and have a baby coming in June so I'm a little freaked out right now)


scott

[wysota]

Classes can equate to Packages and Package bodies, but that's about it!

You'd be comparing PL/SQL to C++ and not to Qt then.

1) Relatively small DB application with a well-designed database, with a properly normalized structure consisting of parent/child, or, master/detail tables
2) No more than 20 tables tops with a small number of rows (at most a couple hundred rows in the largest of the 5 or 6 detail tables)

In a well designed app, to reduce redundancy and save disk space, databases are normalized, but would it make sense with a small application to simplify things, namely the model/view design -- to normalize some data? In the project I'm working on, my detail table will probably never have any more than 50 or so records and the detail table, jeez, no more than say 500...Instead of creating 2 tableviews, 2 SQL models (one for master, one for detail), a QSortFilterProxyModel and managing the relation, would it maybe make sense to just add a column to my detail table and eliminate the master table altogether and apply the QSortFilterProxyModel there? That totally goes against my perfectionist nature, but given time constraints and my inexperience, wouldn't it simplify the implementation by taking me down to one view and 2 models?

Just something I'm thinking about as I'm struggling to figure out where to apply the QSortFilterProxyModel (one example I found applies it to the master, another to the detail -- oooof)

Personally I'd have one large model (maybe not based on sql models) of everything and then I'd use proxies to extract the parts of data I need.

[scott_hollen]

You'd be comparing PL/SQL to C++ and not to Qt then.

Well, yea, but I was thinking more in terms of the actual specific classes within Qt and how they behave...

Personally I'd have one large model (maybe not based on sql models) of everything and then I'd use proxies to extract the parts of data I need.

That does sound like a better approach - thanks for the thoughts!

scott