[Discussion] Versioning support

[solewniczak]

Hello,

I have two ideas about the improvement of versioning support in the struct plugin. If you find them useful, I can implement them into the mainline. If not, I'll try to implement them as struct plugins.

1. I believe that struct table aggregation of page schemas should reflect the "&at=" parameter. Since the page data is versioned, it should be quite straightforward. This will not work when the aggregation page is created after the data pages (we can crate something like the "&struct_at" parameter for this) but can still be useful in many situations.

2. This is more complicated but also worth considering. Since the new serial data is bounded to the concrete page, I believe that is should also be versioned with the page. I think that the best solution here would be freezing the serial data on each page revision. To achieve this we need to simply copy the serial data on each revision and tag it with the correct rev parameter. Maybe this shouldn't be the default for all serial schemas but I think that it should be possible and can be very useful in some use cases.

What is your opinion about this features?

[auto-comment]

Thank you for opening this issue.
CosmoCode is a software company in Berlin providing services for wiki, app and web development. As such we can't guarantee quick responses for issues opened on our Open Source projects.
If you require certain features or bugs fixed, you can always hire us. Feel free to contact us at dokuwiki@cosmocode.de for an offer.

[solewniczak]

I've crated a plugin that support the at parameter for page schemas: structat plugin

I've decided that it would be better to support the at parameter at the syntax level, not as a GET variable, but the idea remains the same. I believe that this feature should be integrated into mainline. What do you think about that?

[annda]

I like the idea of respecting revisions in page aggregations and you are right, it's only logical to integrate it into struct itself. What I'm not quite sure about is whether this should be limited to the aggregation config at, or just make use of the global $REV. @solewniczak Can you elaborate on your reasons a bit?

[annda]

As to versioning serial data, it is complicated. It would probably be easier and safer to introduce an internal timestamp rather than work with page revisions. Otherwise we would have to create new page revisions when editing or even creating serial data, which wouldn't make much sense IMO.

Also, what would editing serial data in historical revisions look like?

@splitbrain What do you think about the idea? Is it worth fleshing out more?

[solewniczak]

@annda I've just upgraded the structat plugin and extended it with the possibility of applying "structat=12345678" as a GET variable - similarly to dynamic filters. I think that this parameter should be independent from $REV or $DATE_AT variables because:

1. When the page with the aggregation is newer that the pages with data, we won't be able to display the rows older than the aggregation page itself.
2. I think that usually we would like to use new aggregation syntax over historic data. If we connects the structat and $REV we automagically assumes that historic data must be viewed with the historic aggregation syntax.

For this two reasons I would recommend to keep the concepts of $REV and 'structat' separate.