That could indeed be a limitation which is no so good. One of the objective of merging is to be able to have discussions on an annotation. We have to have this. Ludovic 2012/2/17 Guillaume Lerouge <guillaume(a)xwiki.com> -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

The problems that I am facing now are related to 2 things: = Approach 1 = If you use only XWiki.XWikiComments (extended with annotation fileds as the pull request is now), you lose the Annotation feature's capability to specify a different AnnotationClass. This means that, if you want to customize the annotation, you need to extend the XWikiComments class directly, and nothing else. This might break existing clients that have provided their own annotation class and will not display their annotations. Writing a migrator for that would imply looking at the configured annotation class that they have provided, update XWikiComments class with the new fields that might be present in that annotation class and convert the annotation objects to use the updated XWikiComments class instead. Would that be enough? This solution will ensure that both "annotation" and "comment" IDs are in the same namespace and are unique. This also ensures that: - the replyTo field points to a proper object ID of class XWikiComments - the html IDs are unique in the page so that the permalinks and anchors for jumping to the annotation and back to the comments tab work - the comments are naturally sorted by ID General downside of solution 1: you lose the ability to change the annotation backend, since you just look at XWiki objects in the page. = Approach 2 = The merging solution has a few problems of it's own: a) The annotation service returns java object Annotations, while the commentsinline.vm works with XWiki API objects. To avoid this problem, we can just do what the old AnnotationsTab did, and that is to directly get the XWiki objects stored in the page using the class configured in the annotations config. Downside: you lose the ability to change the annotation backend, since you just look at XWiki objects in the page. b) Merging things means that we keep both the comments and annotations as separate entities. This means that each have their own ID namespace, causing collisions for the replyTo and permalink features. To avoid this, we would have to do some not-so-nice tricks and mark annotations ID (like "annotation1") so that they are separated from regular comments IDs (when used in the replyTo field). b.1) One solution would be to change the replyTo field's type from Number to String so that we can store this separation. Downside1: This still requires a migration. Downside2: because this means to use the solution for a), we still loose the ability to change the annotation backend. b.2)The other solution would be to use the annotation service API when getting the list of annotations and make a convention when an annotation is created so that it's numeric ID starts from a very large number (like 1.000.000 or more). Downside: Same as problem a): we have to work with 2 types and lots of "IF statements" when processing the comments. Ex: One type has comment.number (for comments), while the other one has comment.id (for annotations). Same thing for dates: comment.getProperty('date').value vs comment.date. General downside of solution2: Since they are merged and no longer naturally sorted by object ID, the comments and annotations also need to be sorted by date. = Conclusion= As I look more into the problem, it does seem that the first approach is the best, having the least number of compromises and doing a better job at semantically merging the two concepts into one. Do you agree? Thanks for your feedback, Eduard On Fri, Feb 17, 2012 at 11:43 AM, Jerome Velociter <jerome(a)winesquare.net>wrote;wrote:

On Fri, Feb 17, 2012 at 12:54 PM, Anca Luca <lucaa(a)xwiki.com> wrote: Yes, exactly that :) IMO we should provide the migrator Jerome -- Jérôme Velociter Winesquare http://www.winesquare.net/

Hi devs, I`ve updated the pull request and pushed a migration script [1], but I`d like a bit of help on 2 issues that I am facing regarding it: 1. Since I have already updated XWiki.getCommentsClass() [2] to add the new fields to the XWikiComments class, I am wondering if I need to do that too in the migration script. If you look at the script that I have pushed, you can see that I have done it [3], but, while testing, it seems that the XWikiComments class is already updated, probably due to XWiki.getCommentsClass() that gets called before the migration. So the question is whether I should keep the updating of XWikiComments in the script or just leave it to XWiki.getCommentsClass()? 2. For some reason, the changes done in the migration script are not saved to the database. I use session.update(...) and session.delete(...) to store my changes, but they don`t seem to be committed to the DB. For instance, the query in my sortCommentsAndReassignObjectNumbers(...) method [4] does not see the objects modified by my previous updateExistingAnnotations(...) method [5]. I must be missing some Hibernate-specific detail, or maybe I am not managing correctly the transaction. Can someone please have a look at the script [1] and point me in the right direction? Thanks, Eduard [1] https://github.com/xwiki/xwiki-platform/pull/34/files#diff-6 [2] https://github.com/xwiki/xwiki-platform/pull/34/files#diff-5 [3] https://github.com/xwiki/xwiki-platform/pull/34/files#L6R109 [4] https://github.com/xwiki/xwiki-platform/pull/34/files#L6R202 [5] https://github.com/xwiki/xwiki-platform/pull/34/files#L6R156 On Fri, Feb 17, 2012 at 5:19 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote: