On 11 October 2016 at 14:40, Uvindra Dias Jayasinha <[email protected]> wrote:
> Thanks for the feedback, some interesting points were brought up > > @Abimaran, the problem with maintaining a rigid structure like old/new > column is that if a user changes the value of 5 columns at a given time > that would mean 5 different inserts to the table, when in actual fact it > was a single transaction that took place when the user did the change and > saved. So its better to use a implementation like > google-diff-match-patch[1] to record the string diff between the values of > the columns before the change took place and after the update. Though we > dont need to worry about this implementation detail for now. The idea of > using a single table to store the history of all tables that will require > auditing sounds good. > IMO we have to think bit more on whether we really need to store the diff correspond to the changes since it may result in a considerable growth of the storage mainly during the development phase. Also the implementation could be complicated in terms of what columns to be considered since the changes may take place in more than a single table for an artifact update. Thanks, Lakmali > > @Sanjeewa, yes this would improve performance when trying to retreive the > LAST_UPDATED_TIME for a given entity. > > Let me elaborate a bit on Sanjeewa's point. So there can be only one > CREATED_BY and CREATED_TIME for a given entity so that can remain as part > of the original entities schema. Having the LAST_UPDATED_TIME as part of > the original entities schema gives a performance advantage on checking if a > given entity has been modified since it was last checked. This is vital for > features such as ETags support for the REST API. So CREATED_BY, > CREATED_TIME, LAST_UPDATED_TIME can remain with the original entities > schema. > > We can still use the master audit table(building on Abimarans idea) to > actually keep track of change history of a given entity, so that table > could look like this, > > ENTRY_ID PK > TABLE_NAME VARCHAR > ENTITY_ID FK > DIFF BLOB > ACTION *VARCHAR* > ACTION_BY *VARCHAR* > ACTION_TIME *TIMESTAMP* > > > > [1] https://code.google.com/p/google-diff-match-patch/ > > On 11 October 2016 at 13:44, Sanjeewa Malalgoda <[email protected]> wrote: > >> I think we can manage audit table while still having CREATED_BY, >> CREATED_TIME,UPDATED_BY, UPDATED_TIME in same tables. So with that >> approach we may never need to do table scan of audit table while fetching >> updates. So each updates will recorded in separate table while original >> table having all relevant information. WDYT? >> >> Thanks, >> sanjeewa. >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Regards, > Uvindra > > Mobile: 777733962 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Lakmali Baminiwatta Associate Technical Lead WSO2, Inc.: http://wso2.com lean.enterprise.middleware mobile: +94 71 2335936 blog : lakmali.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
