[...]combined view ---------------- | server view | | -------------| ==> acts just like a metakit view | client view | ---------------- | deleted view | ----------------
1) Having a view level commit would be incredibly useful.
Hard. I can only suggest: apply only changes to that view, then commit.
I'm not sure what you're after - sometimes a consistent datafile will require changes in more than one view before getting committed (e.g. one view containing totals of another one).
2) The combined view is really a special form of a blocked view.
The whole mechanism of basic view and derived views is reaching its limits. There are *tons* of views one can come up with which could be defined in terms of basic ones. This is one of the areas where language boundaries bite: with a blocked view in C++, Mk4py cannot subclass it somehow, and adjust it for other purposes such as the above.
I've mentioned this before, but I can even create a combined view using views from different storages!
Yes. With modifiable combinations, things become more complex of course - but that's to be expected with updatable derived views (which are not fully supported right now).
All in all, given the fact that I have been learning as I'm going, I think that metakit is really, really close to providing almost full ACID support. Am I kidding myself here?
It is, to a pretty large extent, I agree.
Atomicity: yes, MK uses stable storage.
Consistency: yes, same reason, as long as all views are in the same datafile.
Isolation: this one needs work, it does not apply in single-user usage.
Durability: yes, again stable storage.
Isolation requires more than just collecting changes and being careful to apply them in ways which do not affect others too soon. It also needs to deal with coherence & contention, i.e. what if A adds $100 to a bank account, and B does the same:
A: start: temp = balance; temp = temp + 100
B: start: temp = balance; temp = temp + 100; balance = temp; commit
A: balance = temp; commit
Either A's or B's changes have to be prevented or re-calculated.
Note also that MK's commit-aside is another mechanism to start addressing these issues. The aside file essentially stores the difference between the old and the new state, in a transaction-safe way. This goes even further than the above cases, because commit-aside also properly covers all storage re-structuring changes. Commit aside works at the column level, with the potential to be particularly compact and efficient.
The way I think everything can be made to work, is to store changes (similar to a journal) without actually committing (i.e. a "pseudo commit"), until all users are known to have an up to date view of things. For readers/writers which come to the party later, they can open the unmodified original, and each play back the pseudo-commits. IOW a bunch of layered views, as follows:
original state
|
pseudo-commits
|
uncommitted changesIn a client/server context, this can happen either locally or on the server (since there is exactly one unmodified state and one latest pseudo-committed state).
All of this can be coded at the scripting level IMO. It looks like I will be able to explore exactly such an approach in an upcoming Tcl project. My agony continues because this means that solving it in one language will not make it usable with any other language binding!
-jcw
_____________________________________________ Metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
