All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kevin Hilman" <khilman@baylibre.com>
To: Milo Casagrande <milo@foundries.io>
Cc: kernelci@groups.io
Subject: Re: kernelci-frontend: limitation on X days of data
Date: Wed, 12 Sep 2018 13:20:50 -0700	[thread overview]
Message-ID: <7htvmuxyal.fsf@baylibre.com> (raw)
In-Reply-To: <CAEFW_ihUV+Cs_jHH3vmzaxjN5dOY1h05bSzqHuxR_Fxa+m1Cag@mail.gmail.com> (Milo Casagrande's message of "Fri, 7 Sep 2018 09:50:42 +0200")

Milo Casagrande <milo@foundries.io> writes:

> On Fri, Sep 7, 2018 at 12:36 AM Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> Hi Milo,
>>
>> I have some questions on the front-end limitation we have around a max
>> number of days we load data from the backend (default: 14 days, using
>> the `date_range` option when querying the backend.)
>>
>> From my primitive understanding of the current javascript, this is
>> primarily because current tables basically pre-load all the data. IOW,
>> even if it's configured to only show the first 25 elements, the
>> javascript will actually load all the data on the first load, then
>> when paging, it's just showing already loaded data.  Obviously, if
>> there is lots of data to load, this would be very slow for the first
>> view if/when there is lots of data.
>
> True.
> For the "big" views (/build/ and /boot/) the results are loaded in
> batch (I think 1024 at the time), but it's not leveraging dataTables
> server side logic to do so.
> It's sort of a "hack" around the dataTables logic in order to keep the
> client side search function.

Aha, this is the part I was missing.

I'd forgotten about the client-side search functionality, so now it
makes sense why it's done this way.

So IIUC, there's basically a trade off to be made with having
client-side search and how much data to (pre)load.

To fix this correctly, we really need to implement search server side,
and that's a much bigger change indeed.

Anyways, thanks again for clarifying,

Kevin

      reply	other threads:[~2018-09-12 20:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 22:36 kernelci-frontend: limitation on X days of data Kevin Hilman
2018-09-07  7:50 ` Milo Casagrande
2018-09-12 20:20   ` Kevin Hilman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7htvmuxyal.fsf@baylibre.com \
    --to=khilman@baylibre.com \
    --cc=kernelci@groups.io \
    --cc=milo@foundries.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.