jsaver
A lightweight collection of functions for working with JSON in FiveM. STOP CREATING MYSQL TABLES FOR EVERYTHING AND USE JSON LOCAL STORAGE
Description
Jsaver allows you to store information locally in JSON files without having to create any tables in a database. This script is useful for storing persistent information of all kinds related to the server and accessing it very intuitively through LUA tables.
Usage
This is an example with a data space called `plate’
Create Data Space
--First we have to create the data space
if not exports['jsaver']:Exists('plates') then
exports['jsaver']:Create('plates')
end
Load data into script
--Once we have created our data space, we simply have to save it in an array
Data = exports['jsaver']:Load('plates')
From this point we can work with the table in THE WAY WE WANT
We can handle this array just like a map, a vector, a matrix… WHATEVER YOU WANT
Save your information safety
--There are two ways to save the data
--First way
exports['jsaver']:Set('plates', Data)
exports['jsaver']:Save('plates')
--Second way
exports['jsaver']:Save('plates', Data)
--Third way (Only setting the information, jsaver every one minute store the changed information)
ports['jsaver']:Set('plates', Data)
8 Likes
Is there a way to make ESX use this so you no longer need a separate data base?
It is more intended to create data for certain scripts that need the data after restarting the server, such as, for example, the state of the cars before restarting the server, stock of stores…
What is the advantage of this over MySQL?
One of the advantages you have is that you can have all the information of a sql table stored in an array so that at any time you can access that information very quickly without having to make that query.
Another of its advantages is how easy it is to use and being able to work with data without defining any type of table, without worrying about the type or anything like that.
Finally, another advantage is that by saving information in this way you do not overload the MySQL connector, many servers have had problems because of this, causing the server to give many warnings
1 Like
But isn’t that why databases exists ? To have structured tables with defined types.
Sure a json file can be useful for static data.
But it was note made for this kind of purpose. You could use No SQL if you don’t what to use select statements.
So basically, sure you can put a nail into the wall using a screwdriver, but is it the right tool for the job ?
Just because it is possible, it may not be the right tool.
This system is not made for static data because it lets u save all data contained in an array. So u can have a dinamic array created in server-side and after server restarts it will recover the information contained in the array.
This method is very fast because u have all the information in cache.
Using LUA tables like a map, this method allows u to have a major performance than a SQL Database. In addition, you can have a dinamic data structure because u don’t have any restrictions to save the data into the array however you want.
Do you have any statistics or benchmark data to back this up? I would imagine that after a JSON file gets large enough, you would reach a point of diminishing returns.
It’s more efficient this way because you can use the tables in LUA like a map.
Example:
Array = {}
Array.hello = "Hey, What's up?"
--Recover this information is very quickly because the implement of maps in LUA is by a hash table.
--So, the complexity of get Array.Hello is O(1),
--Obviusly, this way is MORE EFFICIENT than to do a query to a SQL Database.
print(Array.hello) --O(1)
If you want to learn about this you can read the official documentation of LUA implementation.
Sorry, I quoted too much of what you said; let me try again
The performance of SQL cannot be compared with the performance of this system, since the requests to the database are made constantly and do not need local storage, as opposed to the fact that this system is the opposite, the data loads when it starts the script and saves them every X time.
Due to this, obviously the access time to the data by intuition is much faster since the data is stored locally and as I have explained before, the access to the data of an array in LUA is O(1).
In summary, the SQL data system makes constant queries while this system does not make queries, the expenditure of resources occurs when saving the data and extracting it, which obviously does not harm what is really important, such as the modification and selection of data.
I’d be interested to see if this will cause race condition issues when trying to read and write to a large file from multiple parts of a script.
The point is that, you don’t have to be reading and writing to the script.
Simply at the beginning of the script you load the information and later you save it, you do not need to load it again because you are already working on it in cache memory.
In addition, each data space goes in a different file, so the information from data space A will not be mixed with data space B.
Hello, I tried your script but no luck at least for me.
When I try to create the .json file it does not create.
RegisterCommand("kreiraj2", function()
if not exports['jsaver']:Exists('testira') then
exports['jsaver']:Create('testira')
print("crt")
end
end)
This is how I tried but it’s not creating
Did you get some error?
Did you check the permissions that u have? Your F Server needs write permissions to create it
but json files can be dumpable in executors right? they can have all the details on a json files localy right?