Ok, I admit it, months have passed and I’ve still not read the docs fully, or hardly any of the code.
I did though watch the Intro to NoSQL by Martin Fowler video @dirvine posted and understand a lot more than I did about databases (not saying much), or at least the design patterns and terminology of the field. BTW On reflection I think I spent about ten years working on products centred on an something that probably should now be called a graph database, and some of that time helping it integrate with SQL and even unstructured text databases (ever heard of the Scottish Co Memex @dirvine?) - yet I managed to end my career without ever thinking I did much with databases :-). Anyway, the video and simmering questions about applications set me thinking about how one would design SAFE to work with databases, and I’m wondering if I’ve misunderstood something. I also realised that a filesystem is a key value store!
My impression was, that if you modified byte X in a file, it would change the chunk containing byte X and all chunks after byte X. I think this because I think there’s some kind of hash from one chunk that seeds the encryption of the next chunk. Am I wrong?
Because it seems daft if this could be avoided, and would make all sorts of file operations way more efficient, if modifying byte X only changed the chunk containing byte X. For an SQL database, or a filesystem, I imagine this would dramatically reduce the number of PUTS when updating records for example. Hence the issue becomes one not of updating a large amount of data for a relatively small change, but how frequently locally cached chunks get written back to SAFE.
