| « Strata Objectives | Local View of Data » |
Changes of Visibility
April 4th, 2007When updating the database, do you keep things in memeory, or write them out?
Consider joins, which, more or less, need to get written to file, in order to be read. If you add joins, do you want them to be visisble to a query that is made during the same mutation?
If so, then do you add a field to the index, one that asks whether the write is valid? Can you update a record in Strata? Not now.
Joins are binary. They are either on or off. The link exists or it doesn’t. How do you mark one as being invalid? How do you roll it back? Do you include a start and stop?
If there are starts and stops, then there is a chance that, the stop fails, there is rollback, so you’ll need a list of rolled back, a set of rolled back transactions. You can ignore anything that has been rolled back, in fact, you can make a point of erasing it.
You can be updating the indices all along, and then writing out only the failed transactions.
On a join, you can have a record that has the action, which is join or unjoin, and committed.
On a version you can have a committed flag.
Then you can write these out as they occur, and commit the changes, if you perform a query on a bag, you can flush the bag changes.
You’ll have to add a means to update a record in Strata, to update the flag, or insert one that has the committed flag set.
The join is on or off, so the record will have to be added that says that the join is off as of this transaction.
There could be a set of versions to ignore, no, concurrency problem.
An alternate index can reference a version number, and if the item is not found, because it has not been committed, then it is ignored.


