Rafal Somla wrote:
>> 1. I do not understand what you gain from spreading the recording of
>> data change across several locations. As from I can tell, data
>> will be corrupted upon first metadata item that is read and
>> recreated (usually a database). Why not just put the point of no
>> return ahead of calling read_meta_data?
>
> I think what you suggest is to set m_data_changed flag to TRUE just
> before the call to read_meta_data(). This should be ok, but my solution
> makes reporting more precise - if read_meta_data() aborts before
> changing any data, the flag will not be set and the user will not have a
> false warning.
>
> Thus the idea is to set m_data_changed only when we are just about to
> execute a statement which will change data, as low in the call stack as
> possible. To be more precise, to keep our module isolated from other
> code, the flag should be set before we are about to call code which is
> outside backup module and can possibly change data. If we call code
> which is inside our module, then we can always set the flag inside the
> callee, not in the caller (of course, provided that the callee has
> access to the flag).
I think you are making the code more complex without gaining much. Is
it likely that there will be many errors in read_meta_data before
changing any data? On the other hand, there is a risk that when the
code is changed in the future, people forget about m_data_changed and
introduce scenarios where users are not warned. For maintenance
reasons, it is often better to choose a simple, but good enough solution
over an optimal, but more complex solution.
--
Øystein
