[Yanel-dev] Limiting the number of revisions

[Michael Wechner]

Guillaume Déflache wrote:
> Michael Wechner schrieb:
>> Hi
>
> Hi!
>
>
>> There are sometimes content nodes which change a lot and hence 
>> produce a lot of revisions and even if disk space is cheap it's not 
>> always necessary to keep all revisions. This is often true for binary 
>> files and often it's sufficient to have the last 10 revisions or so
>> or only revisions newer than 7 days or a combination of it.
>>
>> Hence I would like to introduce an optional parameter(s) such that 
>> one can limit the number of revisions, whereas
>
> I'd prefer than we inroduce a strategy class 
> (RevisionDeletionStrategy?) instead of many integer parameters, as 
> there are many policies one may want to choose, the default strategy 
> being to never remove any revision of course. Then without enough 
> context one can decide what to do with old revisions, binary or not 
> (maybe only deleting some subset of the binaries may be enough).

doing this more abstract sounds good to me. I will try to make a more 
concrete suggestion of such an abstract "class"
>
> Also I wonder how Yanel itself would react to missing revisions only 
> for some files? That probably always needs application-level handling 
> but I hope Yanel itself is already somewhat forgiving of such hiccups 
> ATM.

well, if of course specific revisions are used by other objects, then 
one will quite probably receive an exception if such a specific revision 
will be deleted.
For example in combination with workflow it can happen that an older 
revision is used as live version and hence by "accidence" gets deleted.
That's a very good point and will think about it
>
>
>> I would like to introduce this for the Yarep virtual file system 
>> implementation and if it proves useful and solid, then maybe we can
>> also  enhance the Yarep API.
>
> ..then we could reference this class from the Yanel API.

exactly. Maybe we need to introduce it right away for cases as described 
above re the workflow problem
>
>
> However before making changes to Yarep, I'd suggest we 1st try to fix 
> the tests and run it under Hudson! ;)

agreed
>
> Also if we have to change the API we should begin versioning it.
> And if we do that it might be a good idea to try to "partition the API 
> by capabilities" (Searchable? Versionable?) like it is done for the 
> resource-type API.

agreed, but I am afraid this will be quite some effort, and I actually 
just wanted to get rid of some revisions ;-)

Cheers

Michael
>
>
> Cheers,
>    Guillaume