Subject Re: View updates and upward compatibility
Author paulruizendaal
We have two viewpoints:
- this behaviour is wrong, undocumented, non-standard, used by very
few app's and a support headache
- changing this behaviour will break thousands of production systems

I do not have hard numbers, I would assume that the most likely class
of app's to break are replication tools. This would indeed be a
support nightmare: people upgrade the engine and suddenly their
replication stops working -- replication vendors get swamped with
support calls and in-house solutions go digging for that old, non-
existing documentation. Heck, it always used to work.

I am somewhat surprised that Sean's suggestion of some sort of
config/dialect based solution did not get more discussion. Seems a
sensible approach to me.


PS For Fyracle the decision does not matter much -- it has its own

--- In, Jim Starkey <jas@n...>
> Claudio Valderrama C. wrote:
> >Ann W. Harrison wrote:
> >
> >
> >>There was discussion and agreement to change the behavior
> >>of naturally updateable views with triggers on the development
> >>list around 30 July 2003 and again in November 2003. Whether
> >>I was on vacation, asleep, or just stupid, I missed it.
> >>
> >>Dmitry and others found dozens of cases where views were
> >>marginally updateable, unreliably updateable, crashed the
> >>system etc. Dmitry's message is below.
> >>
> >>
> >
> >Ann:
> >
> >In our short FB history, controversial changes have been discussed
> >tested in the list. Incompatible changes with previous versions
(where the
> >old versions were considered at fault) were done after general
> >It's almost impossible that "general" equals "unanimous".
> >
> So, you are arguing that a single keyword on future view
definitions is
> too hgih a price to pay to keep thousands of existing production
> working? Or are you arguing that an implicit decision once made
> be reviewed?
> [Non-text portions of this message have been removed]