Re: Problem with aborting entire transactions on error

On 12/10/2012 06:52 AM, Zbigniew wrote:
> 2012/12/10, David Johnston <polobo(at)yahoo(dot)com>:
>

>
> I've got a feeling, that all you have to say, is: "if this is the way
> it is, it means, that this is good, and shouldn't be changed". You are
> unable to explain, why - just the "common belief" etc. is your
> rationale (while it's not that "common" at all, as I wrote). You have
> no arguments against, but: "code it by yourself", "it must be perfect,
> when it works so", and so on.
>
> According to you the development can be stopped at this time, since
> everything is perfect.

Nothing is ever perfect when it comes to software. An error is an error,
sooner or later you will have to deal with it. What you are facing is a
project decision to have the end user deal with the problem sooner
rather than later, one that I agree with by the way. As to why that is
so, experience has shown delaying the solution increases the difficulty
of the fix. I have been reminded of that lately while working on some
data stored in another Open Source database that allows one to run with
the safeties off the foot gun. The original coder went the expedient
route and now that data is a mess. Some of it can be cleaned up, but an
unknown amount is lost or defective. At this point in time there is
insufficient information left to decide on the validity of portions of
the data. The 'common belief' then is that it is better to make the end
user aware of issues from the start and force a solution, for the sake
of data integrity. If you follow the list regularly you will find that
to be the case.

--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com