search

berti92 / mega_calendar

Plugin for redmine: Brings a better calendar and more opportunities to display issues and holidays
http://www.devbert.de/index.php/en/project/megacalendar/
MIT License
70 stars 51 forks source link

Time range queried #121

Closed mael-chouteau closed 1 month ago

mael-chouteau commented 1 month ago

Hi, I'm migration from the version 1.7.1 to 1.9.9.

And now the settings showing the same events for a month is now taking 59 sec instead of the 10 sec before.

I found that before, the plugin would only search for the currently displayed month, and would start new queries when changing the month.

Now it is making queries for all events (over 5 years in our case), it is indeed smoother when changing from month to month, but the initial wait time is way too long.

Can you please help us find what we can change to only query the displayed timespan on the calendar?

Have a great day, Maël.

mael-chouteau commented 1 month ago

Where is an example for the month of august : _https://redminetest.local/calendar/get_events?user=false&save_values=true&filter=%7B%22assignee%22%3A%7B%22operator%22%3A%22contains%22%7D%2C%22assignee_group%22%3A%7B%22operator%22%3A%22contains%22%7D%2C%22status%22%3A%7B%22operator%22%3A%22contains%22%7D%2C%22project%22%3A%7B%22operator%22%3A%22contains%22%7D%2C%22tracker%22%3A%7B%22operator%22%3A%22contains%22%7D%2C%22priority%22%3A%7B%22operator%22%3A%22contains%22%7D%2C%22version%22%3A%7B%22operator%22%3A%22contains%22%7D%7D&start=2024-07-29T00%3A00%3A00%2B02%3A00&end=2024-09-09T00%3A00%3A00%2B02%3A00_

The request to the server is right, but then the server seams to check for all events, not taking into account the time span. And each time we change month, a new request is made, which also request for all events.

mael-chouteau commented 1 month ago

I figured out the problem. The plugin was looking for issues without due dates that start after the beginning of the timeframe we're interested in. So, if we're in August, it also searches for issues in September and beyond.

A similar issue occurs when checking for events that end before the end of our timeframe but have no start date. This means that an issue ending in 2017 might still be included, even though we're only focused on August 2024.

It is corrected in the PR #122 I now have a loading time of 5.5sec where I was getting 1 min before, it is even faster than the old server in version 1.7.1 of the plugin which is getting 18sec for the same request with the same events.

berti92 commented 1 month ago

PR is merged -> CLOSED