Well we released a new version of the Events module last week (5.0.1). Fortunately things were quiet for me on the work front. Whilst we believed we had tested upgrade situations pretty well, even asking for data from various quarters to help with this, we still missed a couple of scenarios.

One person has been using the Events module from it’s early days. (I have as well, but via a forked version of AVCalendar which meant I had to manipulate my data into version 4.0.0 when we released that last year.) This brought with it a couple of data anomalies, blank values in PortalID in the Events table, and a blank EventTimeBegin in the EventsSignups table. So I’ve updated the 5.0.1 SQLDataProvider upgrade script to deal with these, which will come out with the 5.0.2 script – EVT-10192.

The second problem was someone upgrading on DNN 5.0.1. We’d caught one bug in DNN 5.0.0 earlier in testing where a call to GetModulesByDefinition returned a count of 1, even when there were no modules in the portal. 5.0.1 introduced a second bug in the same call, which returned only one module on the portal, when there were several. Consequently only the first modules data got upgraded. Fortunately I’d added functionality (just in case) to allow a modules upgrade to be re-started via it’s module settings. This will be resolved with DNN 5.1.0.

But this led to a third problem. When trying to get the upgrade to run, we found it was timing out. This was due to the fact that there events with weekly events occurring until 2999. This caused three problems:-

• The database was growing substantially because we generate one record per recurrence, and there were huge numbers of recurrences. We will improve on that in 5.1.0 via EVT-10223.
• The upgrade was timing out, firstly because there were so many records being created, but also because of an inefficiency in the database logic. This will be improved in 5.0.2 via EVT-10206.
• Viewing the data was timing out, because there was a huge inefficiency in the code that was retrieving recurrence information potentially 100s of times taking a number of seconds for each retrieval. Again improved in 5.0.2 via EVT-10206.

To try and protect against the future possibility of entering dates that disappear a long time into the future, we also plan to add an admin setting that will limit the number of recurrences of an event allowed. This will come in 5.1.0 via EVT-10199.

The reality is, we didn’t test against a large enough data set, otherwise we would have spotted these performance issues. So if anyone is willing to support testing in a formal way as part of the team, feel free to offer!!