serialized fields are convenient but untidy. We need a proper data structure for extra comment data.

Comments

sanjeev gupta’s picture

Title: remove serialized field in casetracker_comment table » There is no need of casetracker_comment table.

I think that we can store the changed case fields information in the comments table.Its just concatinating the $comment->comment information with the changed case fields information.

killes@www.drop.org’s picture

Title: There is no need of casetracker_comment table. » remove serialized field in casetracker_comment table

I am not sure this is a good idea. If you store the data in the comment field we will have troubles when editing a comment. The status data also can not be retrieved without parsing the comment body.

What I want is that we have the followign table structure for casetracker_comment:

cid, sid

sid is a unique index (auto_increment).

sid appears in a second table casetracker_comment_status:

sid, state, status, priority, type, assigned_to (maybe more)

state can have two values: "before" and "after" (or 0 and 1)

When you display a comment you can then do the following:

SELECT b.status AS status_before, b.priority AS priority_before, ..., a.status AS status_after, a.priority AS priority_after, a.... FROM casetracker_comment c INNER JOIN casetracker_comment_status b ON c.sid = b.sid INNER JOIN casetracker_comment_status a ON c.sid = a.sid WHERE c.cid = %d AND b.state = 0 AND a.state = 1;

sanjeev gupta’s picture

I have incorporated the changes mentioned by you.Everything is well on my local server.But on sandbox the changed case fields are not displayed on the front end.Here case 'view' of casetracker_comment function is not working properly on sandbox.

sanjeev gupta’s picture

Status: Active » Fixed

This issue has now been fixed.There are two tables casetracker_comment & casetracker_comment_status that contains the auxiliary data about comment.

Anonymous’s picture

Status: Fixed » Closed (fixed)