I am sure there are both use cases for automatic vs manual/controlled collection of unused data, however if I were a user I would personally not want to care about this. While I'd be happy to know that my repo is faster / smaller / cleaner / whatever it'd sound overly complex to deal with JCR and Oak constraints and behaviours from the application layer. IMHO if we want to have such a feature in Oak to save resources, it should be the persistence responsibility to say "hey, this content is not being accessed for ages, let's try to claim some resources from it" (which could mean moving to cold storage, compress it or anything else).
My 2 cents, Tommaso Il giorno lun 3 lug 2017 alle ore 15:46 Thomas Mueller <[email protected]> ha scritto: > Hi, > > > a property on the node, e.g. "archiveState=toArchive" > > I wonder if we _can_ easily write to the version store? Also, some > nodetypes don't allow such properties? It might need to be a hidden > property, but then you can't use the JCR API. Or maintain this data in a > "shadow" structure (not with the nodes), which would complicate move > operations. > > If I was a customer, I wouldn't wan't to *manually* mark / unmark binaries > to be moved to / from long time storage. I would probably just want to rely > on automatic management. But I'm not a customer, so my opinion is not that > relevant ( > > > Using a property directly specified for this purpose gives us more > direct control over how it is being used I think. > > Sure, but it also comes with some complexities. > > Regards, > Thomas > > > >
