I agree with you Vincent, by default, everything should be versionable... A property could be made "non-versionable" because sometimes this is useful... Just try not to multiply such options to keep XWiki homogenic
br Pascal On Wed, Jun 18, 2008 at 12:06 PM, Vincent Massol <[EMAIL PROTECTED]> wrote: > I'm +1 for this. > > I see 2 possible implementations: > 1) At the class property level, saying that such property is non- > versionable > 2) At the moment we do a save with an internal api to not generate a > version > > I prefer 1). > > Thanks > -Vincent > > On Jun 17, 2008, at 10:43 PM, Ludovic Dubost wrote: > > > > > Yes.. The use case is to use this for storing information that is > > related to a wiki page but that at the same time can be update many > > many > > times and if we do it would create a huge amount of version and impact > > performance. Not being able to rollback would be a known behavior and > > this would be used for data that we are not interested in history of > > and > > that many times we could recalculate. In many cases it could be to > > store > > aggregate information that would be faster to access. > > > > Example: > > > > - last connection time of a user : it is only available using an > > aggregate query and could be costly to access if you wanted to show > > this > > next to each user. With a non versioned property you would have this > > in > > the user document cache. > > - last update time of a feed in XWiki Watch and number of articles > > loaded (currently this generates tons of versions of the document and > > forces us to clear versions, thus potentially loosing important > > history > > information) > > - average page rating or user rating (this is a requirement of the > > Socracy project http://www.socracy.org) calculated after each rating. > > - watch list adding a page to watch for a user (not sure if this one > > would be a use case as we might want the rollback for this) > > > > These non versioned property could be updated using Groovy > > Notifications > > or could be updated using Groovy Scheduler Jobs.. > > > > The other requirement is about being more efficient when saving which > > also would allow XWiki to be more efficient for application with many > > saves on big documents with many objects and properties. > > > > Ludovic > > > > Vincent Massol wrote: > >> This is a relatively big change and I think we need a vote for this. > >> At the very least Ludovic can you explain the need? > >> > >> This is the first time we would not version something and thus break > >> the "wiki" principle of rollback. Thus we need to be sure it's a > >> valid > >> use case with this in mind. > >> > >> Thanks > >> -Vincent > >> > >> On Jun 16, 2008, at 12:20 PM, Ludovic Dubost wrote: > >> > >> > >>> Artem, > >>> > >>> Can you look at integrating the following jira items in your > >>> schedule: > >>> > >>> http://jira.xwiki.org/jira/browse/XWIKI-2470 > >>> http://jira.xwiki.org/jira/browse/XWIKI-2471 > >>> > >>> The objective would be to support non-versioned properties in XWiki > >>> Objects. Modifications to there properties would never make a new > >>> version of the document. At the same time we would highly improve > >>> our saving by not resaving data that are not changed. This would > >>> have great effect on big documents. > >>> > >>> If we had these in the standard API it would allow us not to write a > >>> separate plugin and storage on a client project. > >>> > >>> Ludovic > >>> > >>> -- > >>> Ludovic Dubost > >>> > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > >> > > > > > > -- > > Ludovic Dubost > > Blog: http://blog.ludovic.org/ > > XWiki: http://www.xwiki.com > > Skype: ldubost GTalk: ldubost > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
