Jacopo ,

Thanks for the excellent explaination.
It makes more sense to me now.

--
Ashish

On Mon, Jun 30, 2008 at 2:11 AM, Jacopo Cappellato <
[EMAIL PROTECTED]> wrote:

> Hi Ashish,
>
> please see my comment below:
>
> On Jun 30, 2008, at 7:50 AM, Ashish Vijaywargiya wrote:
>
>>
>>
>> The reason of keeping the field(statusChangeNote) in WorkEffort entity was
>> that you don't directly update the values in the WorkEffortStatus table.
>> If
>> you update the value for the "status" in the WorkEffort table then the
>> changed value will also gets saved in the WorkEffortStatus table for
>> maintaining the History of status.
>>
>> I am confused that how should we maintain the value in the
>> WorkEffortStatus.reason field.Because the value in WorkEffortStatus comes
>> on
>> changing the value in WorkEffort table.Please let me know your thoughts on
>> this so I will get the better insight on the scenario of keeping only the
>> "reason" field in WorkEffortStatus table.
>>
>>
> The (current)statusId in the WorkEffort entity is a somewhat redundant
> field (denormalized) because the master information is in the
> WorkEffortStatus entity; the reason we keep it is to make it easy and fast
> to get the current status of the WorkEffort; if there is code that creates a
> WorkEffortStatus entry when the statusId of the WorkEffort is changed, then
> this should be interpreted as a convenience method of keeping the data model
> synchronized. We should "read" it in the following way:
>
> "updateWorkEffort to newStatus" --> create a new WorkEffortStatus entry -->
> update the statusId field in the WorkEffort entity to reflect the new entry
> in the WorkEffortStatus
>
> and not in the following way:
>
> "updateWorkEffort to newStatus" --> update the statusId field in the
> WorkEffort entity --> create a new WorkEffortStatus entry  to reflect the
> new statusId in the WorkEffort entity
>
> So, if we do something like:
>
> "updateWorkEffort to newStatus with reason someReason" --> create a new
> WorkEffortStatus entry (setting newStatus and someReason) --> update the
> statusId field in the WorkEffort entity to reflect the new entry in the
> WorkEffortStatus
>
> If we really need to do a lot of queries (but I don't think we have to) on
> the last reason for the last status change, then we may think to add the
> (last)reason in the WorkEffort... but again, I don't think we need to add
> this information right now... that is why I guess David suggested to
> suppress that field.
>
> Cheers,
>
> Jacopo
>
>
>
>

Reply via email to