[FEATURE REQUEST] Increase resolution of ocurred_at in Activities

[ktecho]

It would be nice to have more time resolution (timestamp?) for the Activities:

Right now I'm loging a user in and redirecting it to a page, so there are two events that are registered at the same second in the database. When I check what actions a user has made, I see this:

• User 123 visited page /xxx
• User 123 logged in

So the events are in reverse order. If table had more resolution, the order_by would solve this.

[lcharette]

Is the timestamp in the correct order and with enough resolution in the db, or does this requires to change the db structure?

[ktecho]

It seems to be a timestamp, so it should have enough resolucion. So maybe it's related to the method used to save the date:

But I'm not 100% sure if what I'm seeing is the field having just resolution up to one second or what... I don't currently have a phpmyadmin to do an update set column=now(), but if nobody can test it, maybe I can test it in one or two days when I have one.

[lcharette]

Sounds like a race condition... Sprunje will sort by one column at a time by design, sorting by occured_at and  id could help.

[ktecho]

I don't understand what you mean by race condition in this context. But you're right that sorting by the id too could help. In fact I'm trying in the database and ordering by id desc give me the correct order.

[lcharette]

Well, technically it's not a race condition... It's more that the two events happens at the same time and the system (db) is not precise enough to catch it.

Note sorting by id in some case can lead to false positive. If a record is altered, or the date not saved as  now, the order will become inconsistent. In this case, sorting by date first, then id (for rare cases where the date is the same) would be better.

[ktecho]

Yes, you're totally right. Would you accept a PR with this change or is it better to do it on my own project?

[lcharette]

PR could be looked at.

[ktecho]

There you have it: #1062