feat: live database updates

[BerkieBb]

Description

This PR introduces Live Database Updates. It changes how player data is updated by making sure only the any updated playerdata field is updated specifically in the database each 15 seconds (configurable). This is not directly live, but live enough to ensure data gets updated fast.

I have tested this myself and fixed bugs along but it's best to make sure this gets tested with others as well. However, don't test in production until a few have tested in a test environment.

This also adds 2 new events that will be triggered from SetPlayerData in qbx_core/server/player.lua
qbx_core:client:setPlayerData
qbx_core:server:setPlayerData

Checklist

• I have personally loaded this code into an updated Qbox project and checked all of its functionality.
• My pull request fits the contribution guidelines & code conventions.

[ihyajb]

Tested these changes solo and ran into no issues. Will test with some more people later tomorrow

[tomiichx]

I'm not really a contributor, but I'm using qbx_core, and I enjoy checking out the latest changes/PRs from time to time 😄

I really like the direction of this PR, but I wanted to suggest one potential improvement. I noticed you're currently looping through the gathered player data and making individual DB calls for each iteration.

As a suggestion, implementing batch saving and wrapping it in a transaction would both improve performance and add safety - ensuring that if any errors occur, nothing gets partially saved (with errors being logged, of course). Batch saving would be significantly more efficient rather than executing queries one by one.

You might also consider going one step further and define a max batch size, and if it exceeds X (e.g. 100), you run an another save function for the rest of the data. This might be overkill though and will most probably never happen 😄

Just a thought that might help make this PR even better

[BerkieBb]

I'm not really a contributor, but I'm using qbx_core, and I enjoy checking out the latest changes/PRs from time to time 😄

I really like the direction of this PR, but I wanted to suggest one potential improvement. I noticed you're currently looping through the gathered player data and making individual DB calls for each iteration.

As a suggestion, implementing batch saving and wrapping it in a transaction would both improve performance and add safety - ensuring that if any errors occur, nothing gets partially saved (with errors being logged, of course). Batch saving would be significantly more efficient rather than executing queries one by one.

You might also consider going one step further and define a max batch size, and if it exceeds X (e.g. 100), you run an another save function for the rest of the data. This might be overkill though and will most probably never happen 😄

Just a thought that might help make this PR even better

My thought was actually that it might be better to do individual PRs so atleast something gets saved. So when one little thing fails, a server owner can catch in the console and either manually update it or check what's wrong/report it. But at the same time now that I think about it, it's not wrapped to catch errors so it'd stop execution which is not good.

[tomiichx]

Hello again, @BerkieBb!

I had to come back here with a PR related question;
We have a jobscreator on our server which allows us to quickly create jobs in-game (Lunar)

However, some players after relogging simply aren't employed somehow, or atleast they don't see the stash/boss menu interaction markers.

I figured the fix could be to switch to ox_target because it always works (don't ask me why or how, it just works), but I'm still not comfortable with having this issue on the LIVE server, because I'm unsure if it's related to lunar_bridge interactions, or a general core bug, and could this PR be the fix?

Also, I'm on the most recent version of the core with no modifications related to groups

Thanks in advance!

[BerkieBb]

Hello again, @BerkieBb!

I had to come back here with a PR related question; We have a jobscreator on our server which allows us to quickly create jobs in-game (Lunar)

However, some players after relogging simply aren't employed somehow, or atleast they don't see the stash/boss menu interaction markers.

I figured the fix could be to switch to ox_target because it always works (don't ask me why or how, it just works), but I'm still not comfortable with having this issue on the LIVE server, because I'm unsure if it's related to lunar_bridge interactions, or a general core bug, and could this PR be the fix?

Also, I'm on the most recent version of the core with no modifications related to groups

Thanks in advance!

This PR won't be the fix for you. Current core does the job well, so it might be an issue with another resource. Also, this should've been posted as a support question in the discord, not on this PR.

[YvanCywan]

Hey, been a while! I know. Saw this PR on my feed and wanted to check it out.

Some pretty decent stuff here.

Also fairly unsure if "live" is the correct way to phrase these db updates. Although, I am less picky about that since anything compared to how it was is relatively "live".