Important: Please read the Qt Code of Conduct -

[Solved] How to identify items/Rows in QStandardItemModel? QUuid sensible?

  • Hello. :)
    I have an unknown amount of "QStandardItemModels": with about 20 columns and a lot of rows each. There is a good chance of several thousand rows being considered in total.

    In some cases I would need the ability to exactly identify a specific row - identification of items is not necessary, but it probably would aid in identifying a row. Also, it would be nice for this identification to be persistent (writable to disk and readable from there), but I could do without that.

    The method used, whatever it may be, should be somewhat fast, (mostly) secure and easy to handle. I would be glad about any kind of input - here the things I have been thinking about so far:

    1) "QUuid": : This does look promising, but according to "a link from within the documentation": I cannot be sure these generated values are unique. Here I am mostly concerned about them being unique even with the program being restarted in between generating sets of them. How solid is the underlying algorithm to generate them?

    2) "QPersistentModelIndex": : I do not expect this to be persistent enough to survive a restart (or is it?), but my main concern here is the existence of several models. Can these indexes be trusted in that case? What happens if I use takeRow() and insertRow()? Would there be a way (probably indirect) of "saving" them to disk?

    3) A good old integer. I have been counting rows and identifying them by their number so far - but that does not only seem quite cumbersome and slow, it also opens up risks of me miscounting at some point. I guess that the chance for (human) error is pretty high here, so I am hoping for something safer.

    Are there any classes I have not encountered yet that could be helpful? Might the persistent ModelIndex be the best solution or is QUuid as trustworthy as I would expect from a Qt implementation?
    As I said before: I would be glad about any kind of input. Have a nice day. :)

    1. UUIDs generated by createUuid() are of the random type. The probability of two random UUID values colliding is exceedingly small even over billions of records. See "Random UUID probability of duplicates":

    2. QPersistentModelIndex is not useful through model resets let alone program restarts.

    1. I know - I included the link you gave (or rather tried to give) in my first post. The question here is: How good is the random number generator behind this? This is what concerns me:
      [quote]However, these probabilities only hold when the UUIDs are generated using sufficient entropy. Otherwise, the probability of duplicates could be significantly higher, since the statistical dispersion might be lower.[/quote]
      The program is restarted every now and then, so I see the possibility of these random numbers being of low quality. But I don't know what Qt does to obtain them.

    2. I just tried a couple of things. It could prove useful later, but not with the current problem.

  • None of the options are of "low" quality but some are not suitable as randomness sources if you wish to secure data against the NSA for periods of years.

    On Windows the UUID generated uses the Windows "CoCreateGuid()": function

    On Linux with "/dev/urandom": (most) the randomness is not good enough for long-term cryptographic purposes but is more than adequate for this purpose.

    On other platforms the random number is from qrand() (a thread-safe C standard rand()) and is not of cryptographic quality... but that does not mean it is uselessly repetitive. The C standard rand() function has a period of at least 2^32.

    If you are really paranoid you can generate a UUID and check it does not already exist in your data set before using it.

  • Well, that information was certainly useful - thanks a lot.

    Concerning the checking of new UUIDs: That sounds expensive - I imagine a couple of thousand UUIDs I have to search through when generating a hundred new ones. So I will rely on the randomness being sufficient and just make a note in the source code, so that I know there might be a source of very unexpected behavior - if anything ever goes wrong.

    Thanks again! :)

Log in to reply