Discussion versioning of data produced by dynamic content macros
The version support for regular pages is an extremely important feature. What about versioning of dynmic content? Confluence has many capabilities that allow for content to be dynamically generated using scripts, sql, scaffold macro, dynamic tasklist, etc... Confluence nicely versions the scripts. Can Confluence be modified to allow the capture of a version of the result of viewing the page? Could this be done on demand - take a snapshot now? Could this be done via a program or scheduled - like take a snapshot every morning at 7:00. Each snapshot would be a version of the dynamic content of the page and treated similar to a regular page version. This would be a powerful capability and would allow more extensive use of capabilities like the scaffold macro (one of the drawbacks of this is that there is no history of what happened on the page).
9 Comments
Hide/Show CommentsSep 07, 2005
Daniel Ostermeier
Hi Bob,
So support this, we would need to modify our versioning support so that, rather that versioning the wiki text, we version and record the rendered text of a page. One problem that I can see with this is we start to lose the actual changes that were made to a page by an author in the noise of the dynamic changes.
Rather than trying to apply this concept to the versioning system, it may be more appropriate to introduce the idea of page snapshots.
So, the existing versioning would work as is, and be focused on the actual changes made to a page, and then the snapshots would be a historical view of a page recorded according to a scheduled task?
Thoughts..
Sep 07, 2005
Mike Cannon-Brookes
I'm not really sure how useful versioning of rendered content would be?
Rendered content is different for every person remember. Based on their preferences, dynamic content, their security settings, link availabilities etc. As such, caching rendered content (as a whole) is nearly impossible. We've looked at such caching solutions before.
I think the only real solution to what you want is to version page meta data along with the page, so that you can recreate any past version at any time? This of course introduces a new layer of complexity.
Cheers,
Mike
Sep 07, 2005
Bob Swift
Yes, this is true in general and a complicating factor. However, there are cases where those things don't matter and don't change the content. The most important part is the time that the snapshot is taken. For example, the results of a query.
Dec 04, 2005
David Peterson [CustomWare]
I agree - rendered content isn't that helpful. For my purposes (cf. Scaffolding Plugin) having properties versioned with a page save would do the trick - as long as I could force a page save even if the actual page wiki content hasn't changed (which will usually be the case when it's dynamic data changing). Then my macros can just request the page to be saved and all the data is versioned correctly. Should I create a Jira request?
Sep 07, 2005
Bob Swift
Yes, definitely still need the versioning of the page markup just like now.
Sep 07, 2005
Praveen Kallakuri
I have been looking for something similar to this... and snapshots seems to be ideal. Our confluence pages mostly show jira portlets.. the data in these portlets ofcourse keeps changing, but it would be ideal to take a "snapshot" of the page and archive it. Comparison between snapshots would be great but I am thinking it would open up a whole bunch of other issues. Snapshots would be a great addition even if they cannot be compared.
Sep 26, 2005
Guy Fraser (Adaptavist)
If there's not a JIRA issue already, then please create one as I would certainly vote for it. Over at adaptavist.com we're working on several macros that would really benefit from some form of version control. Having Confluence provide the mechanism for version control (not snapshot of page, that would be grim, better to store the data itself, etc) would ensure better standardisation between macros and then anything that links in to the versioning (such as backups, etc).
Sep 26, 2005
Bob Swift
No, I don't think there is a JIRA issue yet. Perhaps a bit more discussion is needed to clarify what the issue should be? There maybe a couple of different requirement here.
By "data itself" do you mean the data returned by a SQL query (or other dynamic macro) at a point in time? That would work as long as the page could later be rendered using that version of the data. There could be a lot of data. With things like the scaffold macro, it is much closer to just entry data that doesn't change based on time. So are those 2 separate requirements or is there a general requirement that handles both?
Sep 26, 2005
David Peterson [CustomWare]
I think that would be somewhat up to the macro author to determine. If the SQL query results should be cached, then yeah, but I would generally suggest not. Database results are generally meant to be 'live', and will possibly bring a new result every time they are executed.
On the other hand, data stored by some other macros (tasklist, scaffold, etc) don't change so often and are more likely to be useful if persisted.
In these two cases, the distinction is simple: SQL queries are output to the browser, while tasklist and scaffolding data is stored as properties on the page. So, the simple solution is to archive the properties when the page is archived.
Another possibility is to extend the ContentPropertyManager and add an extra method:
If 'archive' is set to 'true', the property will be versioned when the page is. If not, (or if the original version of setTextProperty is called), only the current value is available.
This way, if a macro knows it needs the data to be versioned, it can set it explicitly. All other macros work as they always have.
Of course the 'version all properties' method is simpler...