Status 304 Not Modified for events

[temparus]

When requesting a specific event with the if-modified-since in the request header, the API responds with status 304 Not Modified although the signup count has changed in the meantime.

This results in a wrong signup count being displayed on the website.

[NotSpecial]

Ahh thats a tricky one ...

The count is never saved in the database; After the event has been fetched from the database, the counting is done and added to the response. And afaik EVE decides on whether to send a 304 on the database only, so an updated count is not recognized.

An obvious solution would be to actually add it to the database, but maybe there's a better way..

[NotSpecial]

Another possible solution: Update the updated field of the event for every signup it receives. I'm not sure if I really like this option, as the field should indicate changes to the object, and in this case there are none. But we could keep the dynamic counting, which is nice.

[NotSpecial]

@hermannsblum, @cburchert any opinion on this one?

Possible options:

• Keep signup count in the database so that Eve recognizes the change? (Possible troubles of getting signup count and actual signups out of sync)
• Manually the "updated" field without writing the actual number to the database? (A little bit hacky, but should work?)
• Any other ideas?

[temparus]

Another option might that we add an addtional field to the event object just for tracking changes which we remove from the payload before sending the event response.

The field could be a date which reflects the time when the last change to the signups was applied. So this value should be updated whenever an Insert, Update or Delete on a signup linked to the event is performed.

[NotSpecial]

Yeah, that doesn't sound bad either. Basically a counterpart to last_updated. We could simply call it last_signup_updated and update it for every signup event, as you say.

But then again, when I am thinking about this, I wonder if we are not just overengineering things.

Let's say we do the simplest option: After each signup event (insert, update, delete), we call "dynamic count" to compute the number of event signups and write it to the database. That is, we simply make the signup count a field that is update for every signup.

Earlier, I was worried that it might get out of sync. But if that update request fails, I guess an update to last_signup_updated would fail just as well, and this would get out of sync as well.

---

I guess I would now propose to go for the simplest way.

• Add a signup_count field to the event (a real field instead of a dynamic field).
• Add a hook for "on_sign_insert/update/delete" that updates the event singup count.