Improve performance on geometry conflict message #503

New Issue

mpeltriaux · 2025-11-19T13:36:36+01:00

mpeltriaux commented

2025-11-19 13:36:36 +01:00

Status quo

On test01 we see that a quite full database (with test and garbage data) reduces the performance of creating the geometry conflict message (holding all the identifiers for entries which intersect with the current viewed one) remarkably.

As long as the database on production is not as full as on test, we should find a way to improve the performance, so the page will load faster.

Ideas

Deferred loading

We could use the same trick as on parcels: Instead of slowing the whole page rendering down, we simply use htmx to create an ajax call which renders the message. This way the page loads faster again and the message regarding the geometry conflicts might appear a second or two later.

This would need mainly frontend work and a new endpoint for fetching messages for a specific entry (we could also think about fetching all messages for an entry this way)

Dropping geometry conflicts once their entry is deleted

This approach would simply delete all geometry conflicts once a spatial referenced object is being deleted. This would a) reduce the amount of data on the database and b) speed up the creation of geometry conflicts, since we do not have to exclude deleted entries.

But once the entry is restored ('un-deleted'), we have to check for geometry conflicts again automatically.

Next steps

I will make some testing and see which approach is the best for our setting.

# Status quo On test01 we see that a quite full database (with test and garbage data) reduces the performance of creating the geometry conflict message (holding all the identifiers for entries which intersect with the current viewed one) remarkably. As long as the database on production is not as full as on test, we should find a way to improve the performance, so the page will load faster. # Ideas ## Deferred loading We could use the same trick as on parcels: Instead of slowing the whole page rendering down, we simply use htmx to create an ajax call which renders the message. This way the page loads faster again and the message regarding the geometry conflicts might appear a second or two later. This would need mainly frontend work and a new endpoint for fetching messages for a specific entry (we could also think about fetching *all* messages for an entry this way) ## Dropping geometry conflicts once their entry is deleted This approach would simply delete all geometry conflicts once a spatial referenced object is being deleted. This would a) reduce the amount of data on the database and b) speed up the creation of geometry conflicts, since we do not have to exclude deleted entries. But once the entry is restored ('un-deleted'), we have to check for geometry conflicts again automatically. # Next steps I will make some testing and see which approach is the best for our setting.

mpeltriaux added the

enhancement

label 2025-11-19 13:36:36 +01:00

mpeltriaux self-assigned this 2025-11-19 13:36:36 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: IT-Naturschutz/konova#503