Update all? Flush to disk?

[Lucas-S]

Is there a better way to handle mass collection changes than calling update on them all?

Items.Update(items.All())

I notice there is a FlushToDisk() method in the JsonStore layer, Could something like this be exposed for when you have done mass-updates? (this may be hard for those using sqlite as backing however)

[xivSolutions]

These are the kinds of things I'm trying to explore. Update in particular is a little awkward. Although, with SQLite, it's not a problem if all of the update commands are wrapped in a single transaction.

This is where I am trying to figure out a good way to wrap a unit of work around this, also. Easy to do for the "store", more challenging when you need a transaction involving the in-memory List, and the store.

Maybe try out some things on a feature branch, shoot a PR?

These types of little niggles are precisely the type of thing I would like to get solidified from the API perspective before pushing to Nuget.

[xivSolutions]

I would love all the feedback and assistance I can get from this perspective, so do feel free to jump in! :-)

[Assassyn]

I have the same thought doing the Azure provider, but I kept the consistency with other providers.

What do you think to moving the Synchronize/Flush/UpdateToDisk/UpdateWithPersistentStore to BiggyList? Then we should be able to remove the memory lists from Json & Azure implementation, keep everything in memory and just synch when required with persistent store providers?

[xivSolutions]

I had considered that, as it would also play into implementing a Unit of Work approach.

My thoughts were that we are then approaching the point where we aren't providing much value, because then all we are doing is querying a store for some data and shoving it into a list. Which is what we would be doing using any other persistence layer.

I've been trying to figure out a way to do this as an option so that, out of the box, Biggy works in the familiar "list transparantly syncs with backing store." But, if the user (or the specific implementation, such as your Azure provider) needs, one can optionally do something like what you describe, maybe by invoking some sort of BeginUnitOfWork() method. At that point, nothing would be persisted until a SaveChanges() method is called.

I've found a couple ways to acheive this, but each have some drawbacks, and things become . . . complex when we consider that the save to the backing store needs to succeed or rollback, and then the changes to the list need to succeed or rollback accordingly. At least, if we want a truly transactional mechanism.

Lastly, we need to remember that in the context of, say, a web application, the Biggy lists being used would most likely (optimally, anyway) be global. In other words, additions/changes to the list(s) would be immediately visible to other incoming HTTP requests, even if changes had not been pushed back to the store yet.

I'll try to push a spike branch or two up in the next few days of what I was doing to get UOW happening (which resolved the issues I mention above, but introduce some complexity I was hoping to avoid), and maybe you all can see what you come up with too.

I would like to solve both of these problems in an elegant way.