Subject | Re[2]: [Firebird-Architect] View updates and upward compatibility |
---|---|
Author | Dmitry Kuzmenko |
Post date | 2004-10-19T18:03:23Z |
Hello, Jim!
Tuesday, October 19, 2004, 1:05:41 AM, you wrote:
JS> But it is a good excuse. If you want to work on a database without
JS> legacy or mistakes, start your own. But then you won't have any users.
JS> If want to work on a database system that has users, you have to respect
JS> their investment, even their investment in ugly, inefficient
JS> workarounds. I
Ok, what with "ambiguous query" error, preventing to move people their
databases to Firebird 1.x ?
What % of people have problem with that queries, and how much with
double update for simple view with triggers?
JS> If you want to play in the software business, you must accept that
JS> breaking working production systems because you have a better idea
JS> doesn't work. It doesn't mean that your idea isn't better, it just
JS> means that better doesn't trump working.
FB 1.0 was breaking production systems a lot of times. ambiguous
queries check, "implementation limit exceeded" for string
concatenation and other things.
JS> Ann's solution of adding a keyword to create view is backwards
JS> compatible, solves the problem, has minimal impact, and is trivial to
JS> implement (unless we've run out of flags in RDB$RELATIONS).
I think if previous behavior will be returned, after year nobody
will remember that views with triggers ever could update tables
by themselves.
Later people have not used views because they had too many problems -
backup/restore dependent views, views with triggers, views with unions
and so on, even now maybe some bugs still registered for views.
But, bugs goes on, views become usable, and people starting to have
problems with updatable views (with triggers).
Maybe, poll will answer?
--
Dmitri Kouzmenko
Tuesday, October 19, 2004, 1:05:41 AM, you wrote:
JS> But it is a good excuse. If you want to work on a database without
JS> legacy or mistakes, start your own. But then you won't have any users.
JS> If want to work on a database system that has users, you have to respect
JS> their investment, even their investment in ugly, inefficient
JS> workarounds. I
Ok, what with "ambiguous query" error, preventing to move people their
databases to Firebird 1.x ?
What % of people have problem with that queries, and how much with
double update for simple view with triggers?
JS> If you want to play in the software business, you must accept that
JS> breaking working production systems because you have a better idea
JS> doesn't work. It doesn't mean that your idea isn't better, it just
JS> means that better doesn't trump working.
FB 1.0 was breaking production systems a lot of times. ambiguous
queries check, "implementation limit exceeded" for string
concatenation and other things.
JS> Ann's solution of adding a keyword to create view is backwards
JS> compatible, solves the problem, has minimal impact, and is trivial to
JS> implement (unless we've run out of flags in RDB$RELATIONS).
I think if previous behavior will be returned, after year nobody
will remember that views with triggers ever could update tables
by themselves.
Later people have not used views because they had too many problems -
backup/restore dependent views, views with triggers, views with unions
and so on, even now maybe some bugs still registered for views.
But, bugs goes on, views become usable, and people starting to have
problems with updatable views (with triggers).
Maybe, poll will answer?
--
Dmitri Kouzmenko