I’ve pushed some changes to make minor improvements on the logging and add some experimental sync exports.
The new exports aren’t having any issues and run a little faster, however they do require a non-recommended build and so they are disabled by default. If you want to use them just remove the comment block and delete/disable the lua wrapper (and use a compatible artifact, I believe 4510+).
If you do continue running the old exports I have enabled lua 5.4 to reduce memory use and improve garbage collection.
This is not in a release, so you need to download the source to use these. Dunak has some more changes and fixes on the way before we update the version number.
What about 0 values into executes/inserts? it takes it as null and gg we have to change tons of stuff around by 0 to 1.
foa is the job/gang grades which was starting from 0
Shouldn’t the last value be “IS NULL”? Or no never mind that’s for selecting. Do you even need the third value in this case, it should just default to null?
well , lets skip the current querry , it was the last one saw throwing the error about 0 value.
anything else that has to be 0 value on a query comes as nul
examples
job_grade, if has lowest grade (0) it comes null , it just throws an “warning” and updates with null into db
garages , where state is 0 if not parked , it comes with warning and sets null.
tbh changed anything that has todo with 0 just to fix it for now.
Hello! today i go to my pc and try to put my localhost base on my server but when i start and i put my correct mysql_connection_string when i start the server it prompt thi error :
[ script:oxmysql] Error loading script oxmysql.js in resource oxmysql: Error: Set up mysql_connection_string in correct format - ‘mysql://user:password@host/database’
[ script:oxmysql] stack:
[ script:oxmysql] Error: Set up mysql_connection_string in correct format - ‘mysql://user:password@host/database’
can anyone help me ?
Take those warnings with a grain of salt. If a lot happens at once and the return of the query is delayed (which happens during server startup, or when sending a lot of queries in the same tick) then the calculation for query time is inaccurate.
Rather then the query taking that long to be performed, that’s just how long it took for the promise to be resolved due to everything being ran on a single thread. I setup a resource to benchmark total time taken for an export to return a result, using both the wrapper.lua sync exports and the newer javascript async exports (which we then await for sync behaviour). I did the same tests in lua, but the results are massively skewed due to lack of precision tools (like process.hrtime, which gets nanosecond precision).
10,000 fetch queries
[JS] Old sync exports
elapsed time: 6394 ms (average 0.6394ms)
[JS] New sync exports
elapsed time: 4354 ms (average 0.4354ms)
Meanwhile mysql-async, for just 1,000 queries
elapsed time: 101516 ms (average 101.516ms)
Each one of these queries waits for the previous to resolve before executing the next so we don’t end up with false warnings.
Edit
I’ve run two more benchmarks with more useful results (rather than just total and average time). Thanks to gottfried we actually can measure nanosecond precision in Lua using lmprof.