I took a bit of a dive into IndexedDB today. Talk about the callback shuffle, but I can see why they designed it that way.
It is going to take a lot of study and JS prototyping, but I think I have an idea how I might be able to develop an app on the desktop that does not need to use to use node or npm in order to do its job.
I’m certainly not the first person to think that IndexedDB might be useful in that regard.
With that in mind, I “registered” an SQL query into local storage.
Initially, I was thinking of Local Storage as a mini repository of useful queries that could run against SQLite.
Then I began to think… why not ditch SQLLite entirely?
Why depend on a bloated server/binding npm-node apparatus to persist simple e-commerce transactions, when IndexedDB (IDB) already provides this capability in a browser? When I can just use JS to access my data locally in a fast and secure way….
What is the sense of implementing StoreBoss using third party (who are these Githubbers anyway, and will they still be supporting their buggy plugins tomorrow?) adapters over which I have no control whatsoever and cannot have a reasonable expectation of being able to rely on long-term? Why not build StoreBoss around the free, and W3C controlled IDB, but with convenient wrappers to suit?
If the transactional data in Stripe can be stored in a practical way in IDB — which itself is built on the concept of a transaction — and if what is of primary importance to a real-world store owner is the notion of a transaction (or Sale, or Order: call it what you will), then IDBCursor looks like it might play an alluring role in making this metaphor work.
But let’s be clear.
What I mean by a transaction is a retail event that took place at some point that is already in the past. For example, the sale of a tee-shirt. Such an event has temporal attributes, as well as other description, such as value. This event may also be rolled back, by, say, a refund.
This is not precisely what is meant by transaction in IDB.
What IDB means by a transaction ae notions of db integrity when a record that is inserted or deleted in the database in real-time and maybe something goes wrong.
These are two very different things — particularly since StoreBoss is an analytic system, that is to say, a means of reviewing and analyzing virtual events that have taken place in external, production systems — such as WooCommerce, Stripe, or a bank’s mainframe batch processing of merchant DDAs.
Deep dives coming up, but first, a simple example of how you can store a SQL query in the browser.
Interesting how Chrome complains about this, while Opera and FF don’t — providing you allow cookies to be set. Chrome forces you to allow third-party cookies, for reasons I cannot fathom at the moment. but will have to examine more closely down the road, as I do a forensic analysis of security in IDB.
The gallery below is a trivial proof that a query can readily be stored in a kind of query Filofax.
No so trivial is that if I can find a way to hierarchically associate “queries” by store (in an IDB sense), then I might have something. IMS was before my time, but I’m going to see if I can learn something from old school data sublanguages.