[Free] oxmysql - asynchronous MySQL wrapper

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.

Now can be downloaded as pre-release v1.3.0-alpha

I want to do more tests until normal release.

1 Like

What about 0 values into executes/inserts? it takes it as null and gg :smiley: we have to change tons of stuff around by 0 to 1.
foa is the job/gang grades which was starting from 0 :stuck_out_tongue:

Reproducible example? Should make issue rather than rewriting queries so it could be fixed.

1 Like

The query

exports.oxmysql:insert('INSERT INTO addon_account_data (account_name, money, owner) VALUES (@account_name, @money, NULL)', {
					['@account_name'] = name,
					['@money']        = 0
				})

The Error

[      script:oxmysql] Warning: Parameter money has NULL value (Sending nil from lua?) [
[      script:oxmysql]   "INSERT INTO addon_account_data (account_name, money, owner) VALUES (?, ?, NULL)",
[      script:oxmysql]   [
[      script:oxmysql]     "account_name",
[      script:oxmysql]     "money"
[      script:oxmysql]   ]
[      script:oxmysql] ]

also had it for job_grades where was 0 and any querry that’s about to set 0 value… even tried tonumber() but still the same.

Try this, commit should fix your problem

currently running this one , still 0 values comes as null for query :slight_smile:

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?

1 Like

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

  1. job_grade, if has lowest grade (0) it comes null , it just throws an “warning” and updates with null into db
  2. 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.

image

For me v1.3.0-beta works

exports.oxmysql:insert('INSERT INTO users (identifier, job_grade) VALUES (?)', { {'test', 0} })

Also try


how to fix this?

You’re not starting oxmysql or have downloaded the source instead of the build.

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 ?

Set up mysql_connection_string in correct format - ‘mysql://user:password@host/database’

Set up your server.cfg properly.

Heyo, I’m currently making the transfer to OXmysql. and i’m getting below warnings.
Do they matter? The data seems like it’s exporting & importing.

Hi, I want to report an performance issue when updating table.

I only have 100 records but it’s took about 1000-3000 ms to execute the query. Is it normal?

Here is my code:

exports.oxmysql:update("UPDATE owned_vehicles SET state=2 WHERE state=1")

I’m using newest release version 1.3.4.

2 Likes

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.

JavaScript
Low: 0.3462ms | High: 13.4404ms | Avg: 0.43639137999999783ms | Total: 4363.913799999978ms (10000 queries)

Lua
Low: 0.3569ms | High: 13.2664ms | Avg: 0.45843701ms | Total: 4584.3701ms (10000 queries)

1 Like

Thank you for testing and explaining to me.

Now with transactions support and new faster optional JS wrappers

Many things was also fixed from 1.2:

  • type casting tinyint, dates,
  • parameters parsing
  • error logging
  • support for RedM
3 Likes

I hear dropping back to 1.2 stops all errors and warnings :nerd_face:

1 Like