XWiki Platform
  1. XWiki Platform
  2. XWIKI-12990

Displaying a livetable list filter for a non-static list field is not scalable

    Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 7.4
    • Fix Version/s: 10.1-rc-1
    • Component/s: LiveTable
    • Labels:
    • Difficulty:
      Unknown
    • Similar issues:

      Description

      A good example of this is the Ideas Application, which define the assignement field like this:

      'assignement': {"type":"list","size":20,"link":"field", "html":true},
      

      this field is of type List Of Users, and a a wiki with thousand of users, it cause the request to run for so long that it timeout. This made the Ideas Application unusable on a wiki with lot of users.

      The same is obviously true for any list field type that could return a very large list of potential values.

      We have a couple of options:
      1) timeout the preparation of the list somehow, returning an erreur, but ensuring it does not runs for hours.
      2) switching to a text filter when there is too many items for a list filter
      3) disallowing list filter on list field type that is not static

        Issue Links

          Activity

          Hide
          Marius Dumitru Florea added a comment -

          Denis Gervalle I doubt you use "type": "text". Isn't it "type": "list"?

          Show
          Marius Dumitru Florea added a comment - Denis Gervalle I doubt you use "type": "text". Isn't it "type": "list"?
          Hide
          Denis Gervalle added a comment -

          Sorry, it was a typo, I made several tests... I fixed the description.

          Show
          Denis Gervalle added a comment - Sorry, it was a typo, I made several tests... I fixed the description.
          Hide
          Vincent Massol added a comment - - edited

          Pierre fixed the issue by having a check on the list size and when < 1000, the filter becomes an input box (ie option 2 from the options described above).

          Show
          Vincent Massol added a comment - - edited Pierre fixed the issue by having a check on the list size and when < 1000, the filter becomes an input box (ie option 2 from the options described above).
          Hide
          Marius Dumitru Florea added a comment -

          I really don't like using magic numbers. Why 1000 and not 100? We need a better fix.

          Show
          Marius Dumitru Florea added a comment - I really don't like using magic numbers. Why 1000 and not 100? We need a better fix.
          Hide
          Vincent Massol added a comment -

          I think it would still have been better to keep it and not revert it for 9.7 and then further improve it later on in another JIRA issue if you have some better ideas rather than not do anything in 9.7.

          Could you at least explain what you intend to implement?

          Show
          Vincent Massol added a comment - I think it would still have been better to keep it and not revert it for 9.7 and then further improve it later on in another JIRA issue if you have some better ideas rather than not do anything in 9.7. Could you at least explain what you intend to implement?
          Hide
          Marius Dumitru Florea added a comment -

          Denis Gervalle I implemented XWIKI-5146 and XWIKI-9639 by introducing a "suggest" live table filter type for Users, Groups and DBList xproperty types. This means the live table author can choose between the current "list" filter type, that works fine when there are not many values to choose from, and the new "suggest" filter type that works best when there are many values to choose from. In your case the live table configuration would be:

          'assignement': {"type":"suggest","size":20,"link":"field", "html":true},
          

          or simply

          'assignement': {"size":20,"link":"field", "html":true},
          

          because the Live Table macro now has defaults for filter types based on the xproperty type. Do you think this is enough to close this issue?

          Show
          Marius Dumitru Florea added a comment - Denis Gervalle I implemented XWIKI-5146 and XWIKI-9639 by introducing a "suggest" live table filter type for Users, Groups and DBList xproperty types. This means the live table author can choose between the current "list" filter type, that works fine when there are not many values to choose from, and the new "suggest" filter type that works best when there are many values to choose from. In your case the live table configuration would be: 'assignement': {"type":"suggest","size":20,"link":"field", "html":true}, or simply 'assignement': {"size":20,"link":"field", "html":true}, because the Live Table macro now has defaults for filter types based on the xproperty type. Do you think this is enough to close this issue?
          Hide
          Denis Gervalle added a comment -

          Marius Dumitru Florea, thanks for these improvements that sounds really great and appropriate in the long term. However, IMO, we cannot consider that developers will make wise choices with the filter type, and so that it might happen that they use the list one for too large numbers of entries. Therefore, I would like to see at least one of the proposed solutions above implemented, probably 1 or 2. I know you don't like magic numbers, but it is even worse to have an infinite waiting time. Just take the example of the idea application, until it is fixed you still have the issue. So enforcing a bit with a magic number, what you are stating above, that "list" type is for small list, would be nice to have before closing this issue.

          Show
          Denis Gervalle added a comment - Marius Dumitru Florea , thanks for these improvements that sounds really great and appropriate in the long term. However, IMO, we cannot consider that developers will make wise choices with the filter type, and so that it might happen that they use the list one for too large numbers of entries. Therefore, I would like to see at least one of the proposed solutions above implemented, probably 1 or 2. I know you don't like magic numbers, but it is even worse to have an infinite waiting time. Just take the example of the idea application, until it is fixed you still have the issue. So enforcing a bit with a magic number, what you are stating above, that "list" type is for small list, would be nice to have before closing this issue.

            People

            • Assignee:
              Marius Dumitru Florea
              Reporter:
              Denis Gervalle
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Date of First Response: