I do remember asking Magic for this back in the old site but it was turned down because (iirc) Inventor caches the storage so it won’t be accurate enough for the usage people would use it for. Also, at that time, Magic was thinking of adding an optional crate usage cap to DBs to automatically delete old rows when the crate usage gets to the specified limit
This was and is correct. In the (hopefully near) future, DBs will support storage crate caps with rolling deletion (like a security camera that always retain the last 2 weeks of footage, you’ll be able to set a fixed number of blocks to be retained. This is useful for things like message loggers).
My primary concern is/was around people trying to homebrew their own version of that system, since it can cause performance issues if people are frequently deleting large amounts of data (especially if it ‘caught on’ and started being a large number of users, each deleting large amounts of data, for example through a library listing or similar).
We’ve seen this happen in the past where a large enough group of users/bots start performing an action frequently enough that it begins to cause performance issues for other users, and that behavior either has to be built into the platform or restricted.
This should primarily alleviate the need for this, but I can still see how getting this data could be useful (for example, notifying yourself when you run out of storage) and think that once that feature is released, it might be worthwhile to implement.
This is sort of a can of worms.
Inventor has a lot of internal ‘guarantees’ based on the idea that some things are only editable from the website.
Separating logic in this way prevents a lot of difficult to debug, configuration-specific, edge-case style bugs (which are already really common with Inventor), so it is something that happens with a lot of care and attention.
Just imagine a flow that created other flows, or a flow that inserts a new block into itself as its running, and the kinds of weird issues and edge-case problems that would arise from a system like that (variables not being referenced properly, issues with escaping values, etc). Those are both things that have been requested in the past, and break this “line” between the website/flow editor and what is available in the runtime.
Databases and Global Vars are the notable exceptions, where you can edit their data from a flow or the dashboard, but some highly-requested features (like a trigger for when a GV or DB is edited, etc.) haven’t happened due to concerns around breaking this boundary (and in that specific case, infinite loops within the platform).
I’d love to enable more of this kind of functionality, but there needs to be systems in place on Inventor to ensure that critical actions are throttled as needed, and that it doesn’t cause any external damage or issues with related systems. Unfortunately, there’s a lot of other stuff that takes priority right now so this is more of a long-term consideration than an actively-planned area of expansion.