#Data
1 messages · Page 1 of 1 (latest)
silly question
it's implementation of storages in js
what benefits do u wait?
you mean the storages that were removed in gmod chromium/js, not silly at all
it's the exact same as cookie.*, reinventing the wheel in a oo format
perhaps add js functions to it so it can be called from js/pass data between states and it'd be useful, but again you can do that with cookie too
Also btw if you set values to nil it won't delete it from the db table
concatenation in sql strings is also dirty and can lead to other issues, maybe look at string.format and/or prepared queries
For example storage:New(";DROP TABLE bla--"), granted you need access to run that but you can avoid all of that entirely
You should use UNIQUE for the key when creating the table. Would be a bit more performant https://sqlite.org/lang_createtable.html#uniqueconst
Although obviously it'd just be best if you used a nonsql database for this, but if you wanna use sqlite that'd at least help
Pretty sure there’s an sql injection in this
Only really when you're creating the store name which a player shouldnt get to influence anyway
One thing I just realised though, this selects everything from the table every time a new store is created. For large tables with lots of keys this will eventually become expensive. The javascript localstorage does not do this, and instead only retrives the value as its accessed and then caches it
Also worth saying that the cookie lib already does all that, and it implements query buffering unlike this one
So when would I use this instead of the cookie library or even raw SQL?
never i guess? i don't see any benefits from gm_datastorages, it uses sql internally, so why not just use raw sql then ||(i also saw one query that has no sqlstr, but... we'll not talk about it, right? :D)||