This HTML document wrapped in a .PDF is the schema description export from the SQLite database I have been using largely unchanged for 7 years. If this database was a Yugo, the new database structure would be a Porsche. It’s quantum magic which uses Lua scripting logic compiled into the SQLite database so the two work together seamlessly. (This is a big part of getting the framework to connect hardcore logic analysis to all the data, itself pursuant to incorporating a portable AI consultant for the vault.)
I thought it might be of historical interest to see what I had working previously and indicate where it is going next.
I don’t need all the subtables to hold the MANIFEST breakdown, signal breakdown and normalization of all these tables to maintain the entire control scheme of all devices connected.
I have successfully replaced all of this crap with JSON single key files which describe data schemas for JSON-RPC which the whole system is based on now. It has all become marvelously simple compared to what I had before.
All the complex processing is done in LUA in the back-end, not on browser requests. Even the LUA “server pages” I used to implement are not as necessary now … I have not resorted to a single one yet in the front page desktop.
I have triggers operating now for things like when marked inventory quantities change, the trigger kicks off a database update from an embedded LUA script inside SQLite running as a co-routine and it doesn’t interfere with the main program at all.
So you add a single box of rice to inventory, all projections and charts for the duration of food stocks will change in your database which in turns kicks off the websocket to tell that a pie chart being displayed in the main window should update itself as well. This has become a very responsive way to keep these things tallied in real-time. No more need to run “the food summary” or “fuel summary” or “water summary” or other complex calculations as outside processes. I have triggers on everything that are all set up in the database the first time you run the program. I have everything connected with unique ids (UIDs) I talked about earlier. Connected by foreign keys so the logical connections are made at the outset.
Finally, that brings me to the fundamental way that the database is built when the program starts up.
For the past 22 years, the database is built the first time you run the program by looking at extensive tables of compiled-in binary lists to construct it. I have done away with that.
The application is now capable of direct execution of text files of SQL commands, even very complex ones with foreign keys and triggers of all kinds. It can execute specialty SQL fragments that may be targeting other databases in the system connected to processes.
What this means is that if the database changes, new SQL patches can be executed to alter the old database without losing data!!!!
A running record is kept of all patches and they are included in the installer/updater so all you do is install the program and I have a patch that will transform the current existing database into the new version without damaging any of your records you have meticulously entered.
I saw this as the best possible anticipation of the program’s scope even as the first versions are issued as “prototypes.” Data will not be destroyed by updated versions.
There are also importers for .CSV and Excel files which may be of great assistance in copying your own existing records of inventory over into the VSYS inventory tables as well as things like Personnel.
I hope this will keep people interested as I progress towards the release of the alpha version.
I really feel I have got the design correct this time around - or as good as could be expected after working on it for 25 years. I wanted the first version to be a drop-down jaw-hits-the-floor eyes-bug-out spectacle.
I am very grateful to my subscribers for believing in a crazy person for this long and gambling that I am going to do it. I can assure you that even as recently as two years ago, I was floundering but I believe I have nearly perfected the vision I originally had of something from a science fiction movie that runs with the reliability of an Etch-A-Sketch when it launches the first time.
Best of all … still no threads. Not even one. Even I can’t believe it and I wrote the code.
P.S. The DACUNITS table may look like an exact copy of the BACNET standard and it is. A very effective way to categorize any possible sensor that could ever be connected to the system. There’s still room in that table so it could end up with some new values added that don’t appear in the BACNET standard. For example, medical and custom industrial/scientific sensors and other values that might apply someday.
Regards, Tex