For hours I spent my time debugging my code, trying different approach to the same code function. Looking for one simple invisible mistake, that is when I want to make a delete request to the IndexedDB.

The request are fine without running a single error, the success event fires perfectly. But one thing which is unexpected, the object inside IndexedDB did not vanish at all. The data stay the same without any flaws (but how can that be, when the 'delete success' event fired? IT SHOULD BE GONE BY NOW!). No kidding, for hours I debug my code, yet found nothing's wrong!

Until one moment I found out the datatype of key I gave the request are different from the object I wanted to delete, the object has a key of 4 and I gave the request "4". I'm so pissed at this moment making me googled 'developer rant' and found this site.
Really! God Bless 1 !== '1'.

YAAAY,
finished my first small project today!
It was the final project of my semester in coding and because coding isn't the main focus of my studies there's not much expected from us - new Date, sorting a list and using local storage were among the more 'complicated' things we learned...
So most of my mates just develop/design a small portfolio website or something but my team (2 others and me) wanted to do a little more so we built a progressive web app, complete with service worker for offline functionality and so on, that can take pictures using your camera, save them to IndexedDB, display only the images the currently logged in user actually took and much more... and today is the day all bugs (that we found...) are finally ironed out!
Now I know that still is just the very beginning but now I want to learn mooooore!
Am happy, had to rant. :D

Just reported a minor tracking bug I found on WebKit to the WebKit bugzilla, and I have a few thoughts:

1. Apple product security can be kind of vague sometimes - they generally don't comment on bugs as they're fixing them, from the looks of it, and I'm not sure why that is policy.

2. Tracking bugs *are* security bugs in WebKit, which is quite neat in a way. What amazes me is how Firefox has had a way to detect private browsing for years that they are still working on addressing (indexedDB doesn't work in private browsing), and chrome occasionally has a thing or two that works, with Safari, Apple consistently plays whack-a-mole with these bugs - news sites that attempt to detect private browsing generally have a more difficult time with Safari/WebKit than with other browsers.

I guess a part of that could be bragging rights - since tracking bugs (and private browsing detection bugs, I think) count as security bugs, people like yours truly are more incentivised to report them to Apple because then you get to say "I found a security bug", and internal prioritisation is also higher for them.

Turns out Chrome really dislike to parse, save in indexedDB, query some things, and draw a graph of some JSON file.
Or, you know, maybe, an average response size of 5Mb is a bit too much.

If you ever need a good example for bad API design, just use IndexedDB. While it might still be far above absolute zero, it should definitely be low enough for any practical purpose.

And as a bonus, it wouldn't actually have been needed if the SQLite status quo would just have been adopted as the standard back then. We could have a complete RDBMS with almost full SQL support in the browser...

The guts, i mean WTF?

Tried learning client side storage and the lord of the best practices (google) were like "WebSQL deprecated,use Indexed DB instead".. said fine,im up for skill level-up

...

That was 2 years ago and WebSQL is fully supported upto Android 7.1 yet i dont see no buzz about indexedDB, user s i have to support are mostly on Android 5.0 (which has excellent support)...come on...pick a side and leave devs out of your batshit crazy politics.

First let me start this rant by saying: Don't use SharePoint lists as your primary data store if you can avoid it. You're gonna have a bad time.

My coworkers and I work on a system where we need to pull tons of data down from a SharePoint site and run various algorithms and operations on it. Generate reports, that sort of thing. This is all done in the browser using a Typescript React SPFX webpart. Basically using SharePoint as a DB/DAL.

Because of the sheer amount of data we end up pulling down (our system in production is the single source of truth for one of the largest companies in Canada, and they're currently building a pipeline as we speak), in order to maintain a reasonable speed while using it, we have some pretty intense caching logic implemented, logic that ensures we get new items when new items are detected, and merges changes to already exisiting objects. It's pretty brilliant, and that's before we even consider the custom paging that my coworker implemented in order to get around the IndexedDB max size of 100MB.

Well that's all well and good, and works great in production, but it is a horror to work with. Because EVERYTHING we touch on the server is cached locally, it can be IMPOSSIBLE to detect data anomalies, be they local or server side -.- You don't know how many hours I have completely WASTED fixing a "bug" that didn't really exist... Just incorrect data in the cache

Darn. I've always been storing images on IndexedDB in ArrayBuffer format. Didn't know you can actually store a File inside, not before a bug that I encountered just now. What a waste of potential 😑