Attribute table opens much faster when "limit fetched data to the current map canvas..." is active

[gioman]

What is the bug? (in English)

So, when opening the attribute table of a vector there seems to be a 500 records limit hardcoded somewhere. I cannot find any reference about it in docs or in LM plugin (but I may have overlooked it of course).

Anyway, knowing that open a project with a layer that has many features (polygons in my case) and choose and extent that shows about or more than 500 features. Then open its attribute table:

the time to open the table with the "limit fetched data to the current map canvas..." option active is a fraction of the time it takes without that option active.

It seems to me that using "limit fetched data to the current map canvas..." should be the obvious default choice, and leave not the other way around. Also it would be better if that option could be set per layer rather than per project.

Anyway, the 500 records limit raises an extra question: how they are chosen? This is especially relevant when "limit fetched data to the current map canvas..." is not used.

Also... it seems to me that whatever makes faster opening the table with "limit fetched data to the current map canvas..." active should be applied also to when that option is not active... with the additional question: how to show records after the first 500?

Steps to reproduce the issue

Open a project with a layer with about or more than 500 features, with attribute table active.

Set the map canvas extent so to see about or more than 500 features.

Open attribute table and compare speed with "limit fetched data to the current map canvas..." active or not active.

Active:

Screen.Recording.2025-05-19.195432.mp4

Not active:

I can't upload the screencast as it is too big, as it takes around 1 minute to open the attribute table (compared to the ~2 seconds of the other case)

Versions, safeguards, check summary etc

Versions :

• Lizmap Web Client : 3.8.9 - commit 643ccc5 643ccc573
• Lizmap plugin : 4.5.0
• QGIS Desktop : 3.40.7
• QGIS Server : 3.40.6
• Py-QGIS-Server : 1.9.4
• QGIS Server plugin lizmap_server : 2.13.1

List of Lizmap Web Client modules :

* lizmapdemo : 3.6.0a1

List of safeguards :

* Mode : safe
* Allow parent folder : no
* Prevent other drive : yes
* Prevent PG service : yes
* Prevent PG Auth DB : yes
* Force PG user&pass : yes
* Prevent ECW : yes

Check Lizmap plugin

• I have done the step just before in the Lizmap QGIS desktop plugin before opening this ticket. Otherwise, my ticket is not considered valid and might get closed.

Operating system

Ubuntu 24.04, Windows 11

Browsers

Chrome

Browsers version

latest

Relevant log output

[gioman]

I have noticed that on a different project the attribute table shows all records as expected.
Differences: where it show fully the table is about 2500 records, postgis. Where it shows only 500 is about 1M records, GPKG.

[gioman]

Opening the table with ~2500 records is also fast, and "limit fetched data to the current map canvas..." was not used.

[Gustry]

Hi @gioman

Lizmap Web Client : 3.8.9

When you did the right click step in Lizmap plugin, you should have a warning telling you that you were not running the latest bugfix about LWC.

LWC 3.8.10 is available :

Regression about the attribute table being limited to 500 features

Can you try again with the latest release of LWC ? 😉

[gioman]

Hi @gioman

Lizmap Web Client : 3.8.9

When you did the right click step in Lizmap plugin, you should have a warning telling you that you were not running the latest bugfix about LWC.

LWC 3.8.10 is available :

Regression about the attribute table being limited to 500 features

Can you try again with the latest release of LWC ? 😉

@Gustry you are totally right on both counts, I'm guilty. In my defense... is not always possible to update as soon as the notification shows. My real error was not reading the changelog.

I have updated and anyway the observations that lead me to file this ticket are still valid (minus the 500 records thing): without "limit fetched data to the current map canvas..." active opening the table is much slower, also seems to me that the logic of "limit fetched data to the current map canvas..." should be the other way around and be opt out instead of opt in, this because otherwise for very large tables it will never finish to load (or as alternative apply the same code that makes table load faster when "limit fetched data to the current map canvas..." is on).

[gioman]

it will never finish to load

it took many many minutes, but ultimately it loaded the full 1M records table. To resume the options you may want to consider:

1. make "limit fetched data to the current map canvas..." opt out, not in
2. make "limit fetched data to the current map canvas..." configurable per layer, not project
3. allow switch on/off "limit fetched data to the current map canvas..." per layer, in LMWC GUI
4. fix opening the attribute table when "limit fetched data to the current map canvas..." is off, because when is on, the same table (and same number of records/features) opens magnitudes times faster (for about 500 records is about 1 minute VS 2 seconds).

[Gustry]

@Gustry you are totally right on both counts, I'm guilty. In my defense... is not always possible to update as soon as the notification shows. My real error was not reading the changelog.

No worries, it was exactly why 3.8.10 has been released "not within the monthly release" because this was flagged a "big regression" for users.

About attribute table, there is a big refactoring done #5562 (which should let user open a million of lines in the attribute table if I am correct)

[nboisteault]

Many (all?) issues described here will vanish in Lizmap 3.10.