Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Delay in fetch calls when multiple combo boxes are pointing to same datasource

    We have an application containing a list grid with more than 30 columns and all the columns are combobox items.
    All the columns are associated with a single datasource.
    When the application is loaded there is a server call for fetching data of each column. (setAutoFetchData is set to true)
    Now since smartgwt forms a queue of calls for the fetch and the response is returned only after all the calls are done (The end time of each calls is equal to the queue end time), there is a delay in populating the data. This causes the filtering to not work properly when something is typed in any of the text editors of the comboboxes.

    Is there anything that can be done to improve this fetch call? Also, can we access the queue and process the calls in multi threaded way?

    #2
    First: please remember to post your specific SmartGWT version and edition whenever asking questions.

    Then, could you elaborate on the specific series of events where filtering works improperly? Are these ComboBoxes that appear in the Filter Editor, or that appear in inline editing, or something else?

    In general, if we are talking about the Filter Editor, there would be no way for incorrect filtering behavior to occur due to a delay in a server response - that would seem to require unsupported settings, such as turning off rpcRequest.showPrompt for requests coming from the Filter Editor.

    For editing, listGrid.autoFetchDisplayMap should avoid fetching data until it is actually necessary as part of the end user editing data.

    As far as optimizing this interaction, queuing gives you a great opportunity for optimization, since these are all from the same DataSource. If the results overlap, you have the opportunity on the server side to re-use previous results since it's all part of one HTTP Request. It's also the case that

    Also, you haven't mentioned anything about the data volume, but if it's small enough, you could consider, perhaps just for some of the fields, using a client-side "clientOnly" DataSource that is loaded in advance.

    Finally, parallelizing these requests, while technically possible, is very unlikely to result in a performance benefit. Really, the #1 thing to think about is why your UI is causing ~30 comboboxes to prefetch data that the end user may never interact with. Solve that, and you don't need to worry about paralleism any more, because the requests will no longer be submitted to the server at all.

    Comment


      #3
      The Smartgwt version is 13.0-p20230901 and we are using the Enterprise edition.
      Also, we are talking about was the inline editing in the Combo boxes.

      Our application is designed in a way that we load around 30 combo boxes next to each other and the user tabs through the combo boxes typing out the possible
      value of each of the combobox, and since the request is on the same datasource and a queue is being formed to fetch the data, combo boxes are not populated with
      its corresponding values until every request in the queue is completed. Now, when user tabs and types in the editor with the combo boxes values not populated,
      the filtering does not work correctly.

      We cannot use listGrid.autoFetchDisplayMap because of the requirment to use autofetch data. Along with autofetchdata as true,
      is there a way to get a response parallely instead of waiting for all the requests in the queue to be completed ? Can we access the request queue and alter any properties ?
      Do we have any documentation on the same ?

      The database table we are accessing contains around 100k records.

      Comment


        #4
        Are you saying you start a queue and then have the user type values into multiple different comboBoxes while not allowing any network requests to the server? We hope not, because sorry, that would not be valid usage.

        Let us know the answer to that before we get into any other questions. Note that the framework does not start such a queue. Normal behavior is that each comboBox would issue a request as soon as the user pauses typing.

        Assuming you are doing something valid, there's still a bunch of basic information missing:

        1) are these comboBoxes in a FilterEditor, or are they inline editors?

        2) what do you specifically mean by the filtering not working properly?

        3) you mention you can't use "autoFetchDisplayMap" because of a requirement to use autoFetchData. Where is this requirement coming from and what is that specific requirement?

        Comment

        Working...
        X