[xwiki-devs] Suport for non versioned properties and more efficient saving - xwiki-devs@xwiki.org

Artem Melentyev

16 Jun 16 Jun

6:37 p.m.

New subject: [xwiki-devs] Suport for non versioned properties and more efficient saving

Hi, Ludovic. Ok. At first look: XWIKI-2470: we can add dirty fields to some objects (like doc.isContentDirty) XWIKI-2471: Add new metaproperty to PropertyMetaClass I need some time to think more. About 2471: Can you give an usecase and a rationale for not creating new versions? (see Sergiu's comment in jira) 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.

-- Artem Melentyev

Reply

Ludovic Dubost

10:43 p.m.

New subject: [xwiki-devs] Suport for non versioned properties and more efficient saving

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 devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

Reply

Pascal Voitot

22 Jun 22 Jun

4:43 p.m.

New subject: [xwiki-devs] Suport for non versioned properties and more efficient saving

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 <vincent(a)massol.net> 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 devs(a)xwiki.org 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 devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Reply