Well I don't agree. A classic example of entities relation is party <- person.
One could update only the Person entity - change the lastName. So we update updated_by field only of the Person entity. One could update only the party entity - change the status - so we update updated_by field only of the Party entity. I actually can not think of a table / entity that might not need the two fields. Even if we take ENUMERATION_TYPE - it currently has created_stamp_tx and updated_stamp_tx - why should it not have updated_by and created_by as well ? -- Deyan On Mon, 2010-07-19 at 08:50 -0700, BJ Freeman wrote: > an entity has a relationship with another entity. > so if the main entity is updated those in the relationship will be tied > to the main entity and don't need the two fields. > > yes those that are only updated by person should have the two fields, in > my opinion. > > Deyan Tsvetanov sent the following on 7/19/2010 8:42 AM: > >> Many entities data is not created without a dependence on another one > >> so those should not need those two fields. > > > > This one i didn't understand :) > > > > In general data is being updated either by a person ( user or an > > administrator or a consultant ) or by a process ( the system account ). > > > > > >> > >> > > On Mon, 2010-07-19 at 08:29 -0700, BJ Freeman wrote: > >> there are many operations that are generated by the system levels, such > >> as status change. I can see the entities that are affected solely by > >> users having those fields. > >> I can see some being added but not every entity. > >> Many entities data is not created without a dependence on another one so > >> those should not need those two fields. > >> > >> > >> Deyan Tsvetanov sent the following on 7/19/2010 8:03 AM: > >>> Hi guys, > >>> > >>> another suggestion: to add 2 mandatory fields created_by and updated_by > >>> to all tables by default like created_stamp and updated_stamp. Currently > >>> there columns are added on demand in the entity definition but they are > >>> often needed. > >>> > >>> Examples of usage: > >>> 1) status change - there is no created_by in the entity status table - > >>> party_status. > >>> In general customers would like to know who and when disabled the party > >>> and who re-enabled it. The same applies to orders, invoices, etc. > >>> > >>> 2) Another example for using these 2 columns is entity lock. When an > >>> EntityLockedException is thrown it would be nice to include the > >>> userLoginId of the user who updated the record as well as the time so we > >>> can notify the user: > >>> "The record you are trying to save has been updated by Administrator, > >>> The priviledged 5 minutes 32 secods ago. To cancel your request and > >>> reload the changes click reload. To go ahead and overwrite the changes > >>> done by Administrator click "Overwrite". " > >>> Or so ... > >>> > >>> 3) Record based security - users could be allowed to modify records they > >>> have created even without edit or admin permissions. > >>> > >>> Therefore it would be very very helpful if these 2 columns are present > >>> by default, even if they allow null values to preserve the current code > >>> working. > >>> > >>> -- deyan > >>> > >>> > >>> > > > > > >
