public inbox for [email protected]
help / color / mirror / Atom feedFrom: Aditya Toshniwal <[email protected]>
To: Khushboo Vashi <[email protected]>
Cc: pgadmin-hackers <[email protected]>
Cc: Dave Page <[email protected]>
Subject: Re: Query tool data grid - Infinite scroll vs Pagination
Date: Thu, 22 Aug 2024 16:00:05 +0530
Message-ID: <CAM9w-_nEtPSVBZOowmeN0J380AJwGCxE+giNydEdXRQMZAZ1WQ@mail.gmail.com> (raw)
In-Reply-To: <CAFOhELe2KNz838R8GQ9dL6z6qUmd2iDc1_nY9CSM-bLnYsLMPg@mail.gmail.com>
References: <CAM9w-_mJkHpqE2BSdBsLqOVO4ARaWPDXZGYb5Hn3eMh+sDcOrg@mail.gmail.com>
<CA+OCxozbRmSmRytM2_4_gNvbpqrX0fEyfFVzYPVWH8ftxHchrQ@mail.gmail.com>
<CAM9w-_n6Eo2SBPMjF-SD1NoWD7_RkhKk+=bPC4sYf3QYOP1wog@mail.gmail.com>
<CAM9w-_n2zyK-fGYKedi59Z_t3-6LTfZeD0_Bgz4EWXhrS6=Zuw@mail.gmail.com>
<CANVC+REpfUds0p7intQAwg64=NDk=TQK4HYjri68sy1QqKKDWg@mail.gmail.com>
<CAAj2gHxghgC1Q7XyyzprNjxuXkLJ3_OZH83dN6w33sXOQEyO3A@mail.gmail.com>
<CAM9w-_n+Bw_LULacX9CSDzdUK4Rm0QgqnpThiAa53W-0rqV0pg@mail.gmail.com>
<CAM9w-_mWgZZJskhxr7p3ABvDwdEM=FfGPKfkuBK8jom7wuzrVQ@mail.gmail.com>
<CPVP215MB18231B703A8AAA097C74D49FCFB32@CPVP215MB1823.LAMP215.PROD.OUTLOOK.COM>
<CAG8xnicRwc5JyCBHgsDi-kD5w-AYBt86-C-yQeZBmuYjsy1Lmg@mail.gmail.com>
<CAM9w-_kB2ym2RoU==1=kmBHtABbVJv5azxFwioEnMZVZ6iehSw@mail.gmail.com>
<CANxoLDexeQwhsOrsV83WjwmU8znr+yQrLYriFgqRTVygJbWrPw@mail.gmail.com>
<CA+OCxoxXg2q_H9ZS-7Ae8x65uH5hLTKGtQgqq9oLbmAJCpQWKA@mail.gmail.com>
<CAM9w-_ku-sc8UOQhApDgVJF5wP0SCkVO2EeUXmS_YGzrFp4DQQ@mail.gmail.com>
<CAM9w-_nYNuo=fCgFYhHwjFfcz5N7Z7zCjSskPS7F-R_viUW6Qg@mail.gmail.com>
<CAFOhELe2KNz838R8GQ9dL6z6qUmd2iDc1_nY9CSM-bLnYsLMPg@mail.gmail.com>
Hi Khushboo,
On Thu, Aug 22, 2024 at 3:56 PM Khushboo Vashi <
[email protected]> wrote:
>
>
> On Thu, Aug 22, 2024 at 3:42 PM Aditya Toshniwal <
> [email protected]> wrote:
>
>> Hi All,
>>
>> I'm facing a problem here so request for suggestions.
>> When I select rows, delete them and save the results - the rows are
>> removed from the UI and from the DB. But, the cursor of the select query
>> still has the result.
>> When the page is changed, the rows come back again as they're still in
>> the cursor memory. Same issue when a new row is added or any update is done.
>> One way to tackle this problem is to execute the query again to refresh
>> the data.
>>
>> What do you suggest?
>>
>>
> For delete, you can use scroll
> <https://www.psycopg.org/psycopg3/docs/api/cursors.html#psycopg.ServerCursor.scroll; method
> of the cursor as it takes relative and absolute both the positions but for
> add and update, executing a query is the option.
>
User may decide to delete in between rows. We'll have to keep track of
those rows and skip them manually. It will make things odd and complex.
>
> On Thu, Aug 8, 2024 at 6:39 PM Aditya Toshniwal <
>> [email protected]> wrote:
>>
>>> Hi Dave,
>>>
>>> On Thu, Aug 8, 2024 at 6:31 PM Dave Page <[email protected]> wrote:
>>>
>>>>
>>>>
>>>> On Thu, 8 Aug 2024 at 13:53, Akshay Joshi <
>>>> [email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Aug 8, 2024 at 6:17 PM Aditya Toshniwal <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hello Everyone,
>>>>>>
>>>>>> Just want to share the progress on this. Attached is a quick demo. It
>>>>>> is not complete yet, but I just want to make sure I'm in the right
>>>>>> direction.
>>>>>>
>>>>>> https://drive.google.com/file/d/1B7DuD2Wx2SABGPEEjc8o4RwYcNgu1t_s/view?usp=sharing
>>>>>>
>>>>>> Excellent, I like the new design.
>>>>>
>>>>
>>>> As do I. I do wonder if the ability to enter numbers for the page and
>>>> the from/to rows is necessary. I guess it doesn't hurt.
>>>>
>>> There was a suggestion from @Dave Caughey <[email protected]> to
>>> consider if a user wants to view rows from different pages together. So
>>> I thought of giving some flexibility. Since it will not be used by most of
>>> the users, it is collapsed under an edit button to save space.
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>> On Sat, Aug 3, 2024 at 7:39 PM Gus Spier <[email protected]> wrote:
>>>>>>
>>>>>>> I like the idea of gmail behavior.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Gus Spier
>>>>>>>
>>>>>>> On Sat, Aug 3, 2024 at 5:45 AM Edson Richter <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Love it!
>>>>>>>> I believe the Gmail behavior is a good approach.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> ER
>>>>>>>>
>>>>>>>>
>>>>>>>> Obter o Outlook para Android <https://aka.ms/AAb9ysg;
>>>>>>>> ------------------------------
>>>>>>>> *From:* Aditya Toshniwal <[email protected]>
>>>>>>>> *Sent:* Friday, August 2, 2024 3:53:33 AM
>>>>>>>> *To:* pgadmin-hackers <[email protected]>
>>>>>>>> *Cc:* Usman Khan <[email protected]>; pgAdmin Support <
>>>>>>>> [email protected]>; Dave Page <[email protected]>;
>>>>>>>> Dave Caughey <[email protected]>
>>>>>>>> *Subject:* Re: Query tool data grid - Infinite scroll vs Pagination
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Hackers,
>>>>>>>>
>>>>>>>>
>>>>>>>> I have come up with the following design, which allows:
>>>>>>>>
>>>>>>>> 1. Adjust the range of rows visible, aka Window.
>>>>>>>>
>>>>>>>> 2. Jump to a page number directly based on rows window size.
>>>>>>>>
>>>>>>>> 3. Pagination buttons to move forward and backward.
>>>>>>>>
>>>>>>>>
>>>>>>>> My question is, how should "select all" behave now? Previously we
>>>>>>>> used to fetch all the rows when select all was clicked which actually
>>>>>>>> slowed down as it took time for large data.
>>>>>>>>
>>>>>>>> Maybe add a new button to virtually "Select All Rows".
>>>>>>>>
>>>>>>>>
>>>>>>>> [image: image (15).png]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 2, 2024 at 6:16 PM Aditya Toshniwal <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>> Thank you Dave and others for your valuable feedback.
>>>>>>>> We'll try to achieve what is best for the users.
>>>>>>>>
>>>>>>>> On Tue, Jul 2, 2024 at 5:46 PM Dave Caughey <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I think there's a nice blend between pagination and infinite
>>>>>>>> scrolling.
>>>>>>>>
>>>>>>>> The problem with the *current *infinite scrolling implementation
>>>>>>>> is that the scroll baris scaled to the number of *rendered* rows, so as you
>>>>>>>> scroll down (which renders another bunch of records), it keeps
>>>>>>>> rescaling the scrollbar, so to get the next "page", you have to continually
>>>>>>>> move to the scrollbar (as Aditya says, "*Many users who want
>>>>>>>> access in between rows or last row struggle to do it as the user has to
>>>>>>>> scroll and scroll.*")
>>>>>>>>
>>>>>>>> If instead the scrollbar were scaled to the total number of rows,
>>>>>>>> (e.g., 1000 rather than the initial 25 rows that were rendered), then
>>>>>>>> clicking (say) in the lower third of the scrollbar would would do enough
>>>>>>>> fetching/rendering to display rows 601-625 (or such). Problem solved.
>>>>>>>>
>>>>>>>> Alternatively (or additionally), provide a "jump to row..." button
>>>>>>>> (similar to what Usman is suggesting re pagination) that gives the user
>>>>>>>> control to see a specific bunch of records quickly.
>>>>>>>>
>>>>>>>> But if the issue is that people don't like infinite scrolling
>>>>>>>> because "the user has to scroll and scroll", then fix that specific UE
>>>>>>>> issue, and people will be happy.
>>>>>>>>
>>>>>>>> The concern I have with a paginated solution is if the page
>>>>>>>> represents the maximum number of rows rendered in the results pane, at any
>>>>>>>> one time. Assume I can see 25 rows in the result pane. I.e., you show
>>>>>>>> rows 1-25 for the first page, then you *only *show rows 26-50 for
>>>>>>>> the second page, then *only *show rows 27-50, etc. But when there
>>>>>>>> is a cluster of records of interest between rows 640 and 655, then those
>>>>>>>> records of interest are going to be spread between pages 25 and 26, and
>>>>>>>> will constantly require flipping back and forth between pages. This would
>>>>>>>> be possibly worse UE than the current "user has to scroll and scroll"
>>>>>>>> issue. On the other hand, if your pagination solution includes letting
>>>>>>>> someone nudge the rendered rows up or down a bit so that I can see rows
>>>>>>>> 640-655 all at once (e.g., there's a field where I can type in that the
>>>>>>>> current page should start at row 635, so I can see rows 640-655 all
>>>>>>>> together), then I'm fine with that.
>>>>>>>>
>>>>>>>> However, if ultimately you decide to toss out infinite scrolling
>>>>>>>> for pagination, then please make the (default?) page size be the number of
>>>>>>>> rows you can actually see in the result pane, rather than some arbitrary
>>>>>>>> number (e.g., 50). Having the page size equal to the number of rendered
>>>>>>>> rows means I can quickly step through the pages and hopefully notice a
>>>>>>>> record of interest.... If the page size is larger than the number of
>>>>>>>> rendered rows, then as I step to the next page I *still *have to
>>>>>>>> scroll down to see the last few rows, then step to the next page, then
>>>>>>>> scroll down again, I.e., that would be hideous UE!
>>>>>>>>
>>>>>>>> So my vote preferences are:
>>>>>>>>
>>>>>>>> First choice: keep infinite scrolling, but simply fix the scrollbar
>>>>>>>> scaling and/or give the user the means to quickly jump down by a page or to
>>>>>>>> a specific page
>>>>>>>> Second choice: use pagination, but *only *if there's the ability
>>>>>>>> to see a specific chunk of records on a single page (rather than spread
>>>>>>>> across two), and make the pagination size default to the number of records
>>>>>>>> visible given the height of the result pane
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Dave
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, 1 Jul 2024 at 04:35, Usman Khan <[email protected]> wrote:
>>>>>>>>
>>>>>>>> Hi Aditya
>>>>>>>> I vote for pagination, it would really be helpful for end users.
>>>>>>>> In addition to giving the user the ability to set page size, if he
>>>>>>>> can also select or enter what page he can jump to say 501, 990 etc it would
>>>>>>>> be helpful.
>>>>>>>>
>>>>>>>> On Fri, Jun 28, 2024 at 3:44 PM Aditya Toshniwal <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Unfortunately, there were only 3 responses to this.
>>>>>>>> In that case, we will discuss internally and decide what to do.
>>>>>>>>
>>>>>>>> On Thu, Jun 20, 2024 at 2:46 PM Aditya Toshniwal <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>> Hi Everyone,
>>>>>>>>
>>>>>>>> Request you to share your opinion on this and respond on:
>>>>>>>>
>>>>>>>> https://docs.google.com/forms/d/e/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?...
>>>>>>>>
>>>>>>>> On Thu, Jun 20, 2024 at 1:36 PM Dave Page <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> On Wed, 19 Jun 2024 at 13:42, Aditya Toshniwal <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>> Hi Hackers,
>>>>>>>>
>>>>>>>> Query tool data grid currently pulls the data on load basis in
>>>>>>>> batches. For example, it will initially load only 1000 rows and once a user
>>>>>>>> scrolls to the 1000th row, it will fetch the next batch of 1000.
>>>>>>>> Many users who want access in between rows or last row struggle to
>>>>>>>> do it as the user has to scroll and scroll. If someone grabs the scroller
>>>>>>>> and pulls it down still it will be a good UX and the scrollbar may jump.
>>>>>>>> One reported here -
>>>>>>>> https://github.com/pgadmin-org/pgadmin4/issues/1780
>>>>>>>> One more aspect to this is the in memory data of the query tool
>>>>>>>> which keep on increasing on each scroll, it affects the performance.
>>>>>>>>
>>>>>>>> I propose we should use pagination instead of infinite scroll with
>>>>>>>> the following advantages:
>>>>>>>> 1. Users can jump to any page they want.
>>>>>>>> 2. Users can change the page size on the grid directly.
>>>>>>>> 3. Memory will be used only for visible rows so performance
>>>>>>>> improvement.
>>>>>>>> 4. Predictable UI, no jumping scrollbars.
>>>>>>>>
>>>>>>>> Let me know what you think.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I think there are definite benefits, but there is the downside of
>>>>>>>> having to scroll and click to browse results. Personally I'm fine with
>>>>>>>> that, but I think you should probably poll pgadmin-support for opinions
>>>>>>>> from more users.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Dave Page
>>>>>>>> pgAdmin: https://www.pgadmin.org
>>>>>>>> PostgreSQL: https://www.postgresql.org
>>>>>>>> EDB: https://www.enterprisedb.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks,
>>>>>>>> Aditya Toshniwal
>>>>>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>>>>>> <https://www.enterprisedb.com/;
>>>>>>>> "Don't Complain about Heat, Plant a TREE"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks,
>>>>>>>> Aditya Toshniwal
>>>>>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>>>>>> <https://www.enterprisedb.com/;
>>>>>>>> "Don't Complain about Heat, Plant a TREE"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks,
>>>>>>>> Aditya Toshniwal
>>>>>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>>>>>> <https://www.enterprisedb.com/;
>>>>>>>> "Don't Complain about Heat, Plant a TREE"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks,
>>>>>>>> Aditya Toshniwal
>>>>>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>>>>>> <https://www.enterprisedb.com/;
>>>>>>>> "Don't Complain about Heat, Plant a TREE"
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thanks,
>>>>>> Aditya Toshniwal
>>>>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>>>>> <https://www.enterprisedb.com/;
>>>>>> "Don't Complain about Heat, Plant a TREE"
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Dave Page
>>>> pgAdmin: https://www.pgadmin.org
>>>> PostgreSQL: https://www.postgresql.org
>>>> EDB: https://www.enterprisedb.com
>>>>
>>>> PGDay UK 2024, 11th September, London: https://2024.pgday.uk/
>>>>
>>>>
>>>
>>> --
>>> Thanks,
>>> Aditya Toshniwal
>>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>>> <https://www.enterprisedb.com/;
>>> "Don't Complain about Heat, Plant a TREE"
>>>
>>
>>
>> --
>> Thanks,
>> Aditya Toshniwal
>> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
>> <https://www.enterprisedb.com/;
>> "Don't Complain about Heat, Plant a TREE"
>>
>
--
Thanks,
Aditya Toshniwal
pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
<https://www.enterprisedb.com/;
"Don't Complain about Heat, Plant a TREE"
Attachments:
[image/png] image (15).png (172.0K, 3-image%20%2815%29.png)
download | view image
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Query tool data grid - Infinite scroll vs Pagination
In-Reply-To: <CAM9w-_nEtPSVBZOowmeN0J380AJwGCxE+giNydEdXRQMZAZ1WQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox