You are not logged in.
Pages: 1
Hi AB,
we may agree on fact that audit trail is an half DELorean : it permits to move only to the past.
In some situations i need to determine the future.
So i've thought to do a new class with
an array storing only properties to be changed , one row for each future date.
an EndOfValidityDate , storing the last date of validity of properties actually stored in properties.
a StartOfValidityDate (optional)
methods to manage them
obviously i need a OnAfterRead event on server side , to verify EndOfValidityDate and , if the case, apply pending changes. It could be fired only for classes with audit trail enabled or, also, be independent from it, but associated to the class, to avoid unneeded calls.
I've looked , without success, for it. Can you help me , please ?
tx
Offline
IMHO it sounds like an anti-pattern.
Such a feature would break the persistence pattern, and put some business logic at the DB layer.
All this "DeLorean" mechanism should better stay out of the framework, and be implemented, on server side, in the service logic.
Offline
ok,
I'll redefine creation methods.
tx
Offline
Pages: 1