3 ms·
You definitely shouldn't use this in production. Looking at the code there's: - race conditions everywhere. - bad and inconsistent formatting, which doesn't
by chmod775 6y ago
You definitely shouldn't use this in production.
Looking at the code there's:
- race conditions everywhere.
- bad and inconsistent formatting, which doesn't help with the
- huge if-else monstrosities.
- Also uses synchronous IO and asynchronous IO randomly.
- Uses try-catch liberally, doesn't check the caught errors, and just re-tries blindly forever in some cases.
If you do any parallel updates/inserts/removals with this "database" you're pretty much guaranteed to lose data. Updates are essentially: 1. read table, 2. make changes, 3. save table.
Which at least would work if it was all synchronous.
I know this is going to sound harsh, but building databases is hard for even the most experienced coders, and whoever
wrote this is clearly at the other end of that spectrum.
https://github.com/Devs-Garden/jsonbase/blob/master/tables.js#L1664 https://github.com/Devs-Garden/jsonbase/blob/master/tables.j...
- deleted 6y ago[deleted]
- adamredwoods 6y agoThey're using readFileSync? Doesn't this lock up the thread?
- mbreese 6y agoIt’s been awhile since I’ve looked at JavaScript like this, but I would guess that the thread lock would only exist so long as the read() call is running. That returns and then the write is initiated. It doesn’t look like there is a lock that exists throughout the update callback. If that’s missing, then if you had two threads/processes operating on the same table, you’d all but guarantee one of those update calls would be lost (in the best case scenario). Or maybe there a different locking mechanism in place that my cursory look missed?
- jsf01 6y agoYes. They’re also using fs.exists in the exact way that the official documentation says not to use it.
- 5986043handy 6y agoYes, this feels very much like a weekend hackathon project rather than a finished product, even for its intended use case.