Using 'Comment' functionality requires history... why?

[ronald_van_kuij]

Hi,

We are thinking of using the comment option of Activiti. Comments are however only stored in history tables. So we actually need the history configuration to be at least 'activity'. We do not want this for several reasons
- Performance/Storage of process history information (that we do not need)
- We need to implement houskeeping (which we do not want)
- Even if we 'delete' the processInstance via the api, the comments are not cascadingly deleted

Is there a specific reason for this? We could start 'abusing' process variables, but I do not like that…

(using 5.10-'SNAPSHOT')

[jbarrez]

I think the idea was that a comment is never 'active'.
The moment you post it, is is already historic, and it is never going to change anymore from that point on.

Why does the history level needs to be set to 'activity'?
Because I believe you are right in the reasoning that history level shouldnt have influence on the comment functionality, regardless how it is implemented

[ronald_van_kuij]

The history level needs to be at least 'activity', or better, it cannot be 'none'. The reason for this is that in the CommentManager.java a check for the history being enabled is done. E.g.

  public void insert(PersistentObject persistentObject) {
    checkHistoryEnabled();
    super.insert(persistentObject);
  }
This CommentManager extends AbstractHistoricManager

public class AbstractHistoricManager extends AbstractManager {

  protected int historyLevel = Context.getProcessEngineConfiguration().getHistoryLevel();
  protected boolean isHistoryEnabled = historyLevel > ProcessEngineConfigurationImpl.HISTORYLEVEL_NONE;

  protected void checkHistoryEnabled() {
    if (!isHistoryEnabled) {
      throw new ActivitiException("history is not enabled");
    }
  }

  public boolean isHistoryEnabled() {
    return isHistoryEnabled;
  }
}
and the table is called ACT_HI_CMT, so it is tightly integrated with history. You need all history tables created (there is a relation with http://jira.codehaus.org/browse/ACT-920)

Personally I think, even though comments are not to be changed, the implementation should be different.

[jbarrez]

Yup, indeed. Imho, it shouldn't do that.
I'll have a chat with Tom on that (I think he wrote that part) and see if we can change it.

[edragonfly]

How can I use the "historicTaskInstance" to get comment ? I can not find getComment() method in historicTaskInstance. What can I do? How can I do? Please.

[trademak]

You can use the TaskService to get comments of a specific task id. So you can use the task id of the HistoricTaskInstance as input.

Best regards,

[edragonfly]

?

[jbarrez]

1) No - that would mean fetching more entities in one query which we don't do for performance reasons

2) that would be good. Could you create a Jira so we and you can follow-up?

[edragonfly]

Yes,you are right . I understand .  It is for performance reasons.

Thank you, jbarrez and Thank you,trademak.

[edragonfly]

Thank you , Tijs Rademakers.
I have got it.

——

I do it like this:


List<Comment> taskComments = taskService.getTaskComments(historicTaskInstance.getId());

for(Comment comment : taskComments) {
        CommentEntity commentEntity = (CommentEntity)comment;
        System.out.println(commentEntity.getMessage());
}

——

But , Could you provide following function in next wishful version.
1.   Comment  HistoricTaskInstance.getComment();    //TaskService  provide  getTaskComments(String taskId) method now.
2.   String  Comment.getMessage();                             // org.activiti.engine.task.Event  provide  getMessage()  method now.
If so , Activiti is going to be more convenient.
Or ,  My idea was wrong？

Best regards