Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QSqlRelationalTableModel with multiple Joins?

QSqlRelationalTableModel with multiple Joins?

Scheduled Pinned Locked Moved Unsolved General and Desktop
67 Posts 4 Posters 22.6k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • D devhobby
    8 Feb 2018, 23:28

    @JonB said in QSqlRelationalTableModel with multiple Joins?:

    @devhobby
    You're supposed to be only handling Qt::BackgroundRole special case. The rest of the time presumably you want to return the inherited class's implementation of data(). So: instead of your return QVariant(); catch-all, you want whatever it is (remember I'm not C++) for return base::data(item, role);.
    The idea is: your overload is not called only for the color (which is when role == Qt::BackgroundRole), it's called loads of other times for quite different information (including the text) with other values of role. You were returning an empty QVariant for any other "property" of the cell, including its text! That's how it works.
    BTW, if it's any consolation, I'm as new to this as you are. So I didn't know it worked this way till earlier too.

    Oh ok thanks, it worked!

    Do you know, by chance, in which order are setData() and data() called? When is data() specifically called? When a dataChanged signal is emitted?

    J Offline
    J Offline
    JonB
    wrote on 8 Feb 2018, 23:34 last edited by JonB 2 Aug 2018, 23:47
    #58

    @devhobby
    Well, I presume:

    • setData() is called whenever the data is changed/set
    • dataChanged signal should be emitted by setData() whenever new data is different from current data
    • data() is called many times, with whatever role aspect is wanted, not only by your code but also by Qt code whenever it wants a piece of information

    http://doc.qt.io/qt-5/qt.html#ItemDataRole-enum:

    enum Qt::ItemDataRole

    Each item in the model has a set of data elements associated with it, each with its own role. The roles are used by the view to indicate to the model which type of data it needs. Custom models should return data in these types.

    D 1 Reply Last reply 9 Feb 2018, 00:28
    1
    • J JonB
      8 Feb 2018, 23:34

      @devhobby
      Well, I presume:

      • setData() is called whenever the data is changed/set
      • dataChanged signal should be emitted by setData() whenever new data is different from current data
      • data() is called many times, with whatever role aspect is wanted, not only by your code but also by Qt code whenever it wants a piece of information

      http://doc.qt.io/qt-5/qt.html#ItemDataRole-enum:

      enum Qt::ItemDataRole

      Each item in the model has a set of data elements associated with it, each with its own role. The roles are used by the view to indicate to the model which type of data it needs. Custom models should return data in these types.

      D Offline
      D Offline
      devhobby
      wrote on 9 Feb 2018, 00:28 last edited by
      #59

      @JonB said in QSqlRelationalTableModel with multiple Joins?:

      @devhobby
      Well, I presume:

      • setData() is called whenever the data is changed/set
      • dataChanged signal should be emitted by setData() whenever new data is different from current data
      • data() is called many times, with whatever role aspect is wanted, not only by your code but also by Qt code whenever it wants a piece of information

      http://doc.qt.io/qt-5/qt.html#ItemDataRole-enum:

      enum Qt::ItemDataRole

      Each item in the model has a set of data elements associated with it, each with its own role. The roles are used by the view to indicate to the model which type of data it needs. Custom models should return data in these types.

      What I have noticed:

      1. Double-Click signal on the Table View calls slot function onTableChanged()
      2. onTableChanged() calls data() when it has finished
        <>
      3. Flags are checked
      4. setData() is called if flag is editable
      5. Signal dataChanged is emitted by setData()

      Where's the problem?

      Say I want to allow modification of some cells (name, surname...) and forbid modification of others (primary key, foreign key...)

      I have a vector of immutable columns (0, 3, 5...)

      I have to check if the column being edited belongs to the vector of immutable columns... TWICE!

      One inside the flag() function and one inside onTableChanged()

      • Doing the check in flags() keeps me from modifying the content of the cell (hence, disabling the double-click)
      • Doing the check in onTableChanged() keeps the cells from being added to the vector of cells that need to be coloured by data()

      Both checks are identical, but serve for 2 different purposes: one for disabling the double-click, the other for disabling the coloration.

      All of these events are not sequential. I put a symbol <> in the list above to evidence two apparently unrelated events.

      If these events had been sequential, I would've written only ONE check at the beginning of the event.

      So, the question is: should I keep the situation this way (2 checks)?

      J 1 Reply Last reply 9 Feb 2018, 09:29
      0
      • S Offline
        S Offline
        SGaist
        Lifetime Qt Champion
        wrote on 9 Feb 2018, 07:20 last edited by
        #60

        If you overwrote the flags method correctly, you shouldn't be able to edit the corresponding cell so you shouldn't have to make several checks.

        Interested in AI ? www.idiap.ch
        Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

        D 1 Reply Last reply 9 Feb 2018, 12:00
        1
        • D devhobby
          8 Feb 2018, 15:50

          @VRonin said in QSqlRelationalTableModel with multiple Joins?:

          See https://forum.qt.io/topic/85973/how-to-simply-change-the-background-colour-of-a-cell-inside-a-tableview

          Thanks but before doing that, I was wondering if there's a way to change the content of the cell by directly typing into it.

          I just want to change the data of the cell and, once changed, color that cell in a different color to alert the user of the change of that particular item/cell.

          Seems a lot of hard-coding work... maybe I should find another convenient way... but for now let's see what comes out

          V Offline
          V Offline
          VRonin
          wrote on 9 Feb 2018, 09:26 last edited by
          #61

          @devhobby said in QSqlRelationalTableModel with multiple Joins?:

          @VRonin said in QSqlRelationalTableModel with multiple Joins?:

          See https://forum.qt.io/topic/85973/how-to-simply-change-the-background-colour-of-a-cell-inside-a-tableview

          Thanks but before doing that

          This discussion went on way too long because you didn't bother looking at that link.

          The solution is already presented there. Basically you need a proxy between the QSqlQueryModel and the view that can handle data changes. That link presents you with an example implementation. You can then use the dataChanged signal of the proxy to detect things you probably want to send to db

          P.S.
          Be careful that proxy considers Qt::EditRole as separate from Qt::DisplayRole

          "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
          ~Napoleon Bonaparte

          On a crusade to banish setIndexWidget() from the holy land of Qt

          1 Reply Last reply
          0
          • D devhobby
            9 Feb 2018, 00:28

            @JonB said in QSqlRelationalTableModel with multiple Joins?:

            @devhobby
            Well, I presume:

            • setData() is called whenever the data is changed/set
            • dataChanged signal should be emitted by setData() whenever new data is different from current data
            • data() is called many times, with whatever role aspect is wanted, not only by your code but also by Qt code whenever it wants a piece of information

            http://doc.qt.io/qt-5/qt.html#ItemDataRole-enum:

            enum Qt::ItemDataRole

            Each item in the model has a set of data elements associated with it, each with its own role. The roles are used by the view to indicate to the model which type of data it needs. Custom models should return data in these types.

            What I have noticed:

            1. Double-Click signal on the Table View calls slot function onTableChanged()
            2. onTableChanged() calls data() when it has finished
              <>
            3. Flags are checked
            4. setData() is called if flag is editable
            5. Signal dataChanged is emitted by setData()

            Where's the problem?

            Say I want to allow modification of some cells (name, surname...) and forbid modification of others (primary key, foreign key...)

            I have a vector of immutable columns (0, 3, 5...)

            I have to check if the column being edited belongs to the vector of immutable columns... TWICE!

            One inside the flag() function and one inside onTableChanged()

            • Doing the check in flags() keeps me from modifying the content of the cell (hence, disabling the double-click)
            • Doing the check in onTableChanged() keeps the cells from being added to the vector of cells that need to be coloured by data()

            Both checks are identical, but serve for 2 different purposes: one for disabling the double-click, the other for disabling the coloration.

            All of these events are not sequential. I put a symbol <> in the list above to evidence two apparently unrelated events.

            If these events had been sequential, I would've written only ONE check at the beginning of the event.

            So, the question is: should I keep the situation this way (2 checks)?

            J Offline
            J Offline
            JonB
            wrote on 9 Feb 2018, 09:29 last edited by
            #62

            @devhobby
            Yeah, I don't really understand what you're saying, and I don't seem to have the knack of the miraculous correct interpretations @SGaist comes up with :)

            If I understand right, you should have two different method overloads doing different things for what you want:

            • data(): when called for BackgroundRole, this will look up your vector of changed cells to determine the desired color.

            • flags(): when called, this should look up whether this is to be an editable cell, which depends on column (PK/FK versus others), but not your "edited vector". That will determine whether or not it returns Qt::ItemIsEditable. If it's not editable, Qt won't let it get edited.

            V 1 Reply Last reply 9 Feb 2018, 10:10
            0
            • J JonB
              9 Feb 2018, 09:29

              @devhobby
              Yeah, I don't really understand what you're saying, and I don't seem to have the knack of the miraculous correct interpretations @SGaist comes up with :)

              If I understand right, you should have two different method overloads doing different things for what you want:

              • data(): when called for BackgroundRole, this will look up your vector of changed cells to determine the desired color.

              • flags(): when called, this should look up whether this is to be an editable cell, which depends on column (PK/FK versus others), but not your "edited vector". That will determine whether or not it returns Qt::ItemIsEditable. If it's not editable, Qt won't let it get edited.

              V Offline
              V Offline
              VRonin
              wrote on 9 Feb 2018, 10:10 last edited by
              #63

              @JonB There is one more point: setData should actually do something. QSqlQueryModel::setData is just a return false;

              "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
              ~Napoleon Bonaparte

              On a crusade to banish setIndexWidget() from the holy land of Qt

              J 1 Reply Last reply 9 Feb 2018, 10:22
              0
              • V VRonin
                9 Feb 2018, 10:10

                @JonB There is one more point: setData should actually do something. QSqlQueryModel::setData is just a return false;

                J Offline
                J Offline
                JonB
                wrote on 9 Feb 2018, 10:22 last edited by
                #64

                @VRonin
                Yes, he's supposed to know that from when I pointed him at:

                Ah ha!! Here's what we wanted to know:
                http://doc.qt.io/qt-5/qsqlquerymodel.html#details

                The model is read-only by default. To make it read-write, you must subclass it and reimplement setData() and flags(). Another option is to use QSqlTableModel, which provides a read-write model based on a single database table.

                way earlier! :)

                1 Reply Last reply
                0
                • S SGaist
                  9 Feb 2018, 07:20

                  If you overwrote the flags method correctly, you shouldn't be able to edit the corresponding cell so you shouldn't have to make several checks.

                  D Offline
                  D Offline
                  devhobby
                  wrote on 9 Feb 2018, 12:00 last edited by
                  #65

                  @SGaist said in QSqlRelationalTableModel with multiple Joins?:

                  If you overwrote the flags method correctly, you shouldn't be able to edit the corresponding cell so you shouldn't have to make several checks.

                  The flag() check is:

                      if(MainWindow::isConstColumn(index.column()))
                          QAbstractItemModel::flags(index) & (~Qt::ItemIsEditable);
                  
                      else
                          return QAbstractItemModel::flags(index) | Qt::ItemIsEditable;
                  

                  Qt::ItemIsEditable is only assigned when the cell being modified isn't found in the vector of immutable cells.

                  In data() the check is similar:

                      if (!item.isValid())
                          return QVariant();
                  
                      if(role == Qt::BackgroundRole)
                      {
                          if(MainWindow::cellsEdited.contains(item))
                              return QColor(66, 197, 244, 150);
                      }
                  
                      return QSqlQueryModel::data(item, role);
                  

                  However, removing the check from either part is disastrous:

                  • Removing the check from flags() makes no cell editable
                  • Removing the check from data() makes all the cell blue as soon as the program starts
                  J 1 Reply Last reply 9 Feb 2018, 12:38
                  0
                  • D devhobby
                    9 Feb 2018, 12:00

                    @SGaist said in QSqlRelationalTableModel with multiple Joins?:

                    If you overwrote the flags method correctly, you shouldn't be able to edit the corresponding cell so you shouldn't have to make several checks.

                    The flag() check is:

                        if(MainWindow::isConstColumn(index.column()))
                            QAbstractItemModel::flags(index) & (~Qt::ItemIsEditable);
                    
                        else
                            return QAbstractItemModel::flags(index) | Qt::ItemIsEditable;
                    

                    Qt::ItemIsEditable is only assigned when the cell being modified isn't found in the vector of immutable cells.

                    In data() the check is similar:

                        if (!item.isValid())
                            return QVariant();
                    
                        if(role == Qt::BackgroundRole)
                        {
                            if(MainWindow::cellsEdited.contains(item))
                                return QColor(66, 197, 244, 150);
                        }
                    
                        return QSqlQueryModel::data(item, role);
                    

                    However, removing the check from either part is disastrous:

                    • Removing the check from flags() makes no cell editable
                    • Removing the check from data() makes all the cell blue as soon as the program starts
                    J Offline
                    J Offline
                    JonB
                    wrote on 9 Feb 2018, 12:38 last edited by
                    #66

                    @devhobby said in QSqlRelationalTableModel with multiple Joins?:

                    if(MainWindow::isConstColumn(index.column()))
                        QAbstractItemModel::flags(index) & (~Qt::ItemIsEditable);
                    

                    There is no return statement there??????

                    D 1 Reply Last reply 9 Feb 2018, 12:40
                    0
                    • J JonB
                      9 Feb 2018, 12:38

                      @devhobby said in QSqlRelationalTableModel with multiple Joins?:

                      if(MainWindow::isConstColumn(index.column()))
                          QAbstractItemModel::flags(index) & (~Qt::ItemIsEditable);
                      

                      There is no return statement there??????

                      D Offline
                      D Offline
                      devhobby
                      wrote on 9 Feb 2018, 12:40 last edited by
                      #67

                      @JonB said in QSqlRelationalTableModel with multiple Joins?:

                      @devhobby said in QSqlRelationalTableModel with multiple Joins?:

                      if(MainWindow::isConstColumn(index.column()))
                          QAbstractItemModel::flags(index) & (~Qt::ItemIsEditable);
                      

                      There is no return statement there??????

                      Just a typo when I posted the code to the forum, the actual code has it.

                      1 Reply Last reply
                      0

                      67/67

                      9 Feb 2018, 12:40

                      • Login

                      • Login or register to search.
                      67 out of 67
                      • First post
                        67/67
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved