Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE REQUEST] Increase resolution of `ocurred_at` in Activities #1061

Closed
ktecho opened this issue Jan 28, 2020 · 8 comments
Closed

[FEATURE REQUEST] Increase resolution of `ocurred_at` in Activities #1061

ktecho opened this issue Jan 28, 2020 · 8 comments

Comments

@ktecho
Copy link
Contributor

@ktecho ktecho commented Jan 28, 2020

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

This comment has been minimized.

Copy link
Member

@lcharette lcharette commented Jan 28, 2020

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

@ktecho

This comment has been minimized.

Copy link
Contributor Author

@ktecho ktecho commented Jan 28, 2020

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:

image

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

This comment has been minimized.

Copy link
Member

@lcharette lcharette commented Jan 28, 2020

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

This comment has been minimized.

Copy link
Contributor Author

@ktecho ktecho commented Jan 28, 2020

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

This comment has been minimized.

Copy link
Member

@lcharette lcharette commented Jan 28, 2020

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

This comment has been minimized.

Copy link
Contributor Author

@ktecho ktecho commented Jan 28, 2020

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

This comment has been minimized.

Copy link
Member

@lcharette lcharette commented Jan 29, 2020

PR could be looked at.

@ktecho

This comment has been minimized.

Copy link
Contributor Author

@ktecho ktecho commented Jan 29, 2020

There you have it: #1062

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.