Issue 81652 - view alteration in HSQL is prone to racing conditions
Summary: view alteration in HSQL is prone to racing conditions
Status: CONFIRMED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: recent-trunk
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-17 13:32 UTC by Frank Schönheit
Modified: 2017-05-20 10:44 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2007-09-17 13:32:34 UTC
With issue 49183, we implemented the possibility to alter, using Base's query
designer, the statement which constitutes a view. Which is fine so far ...

Unfortunately, HSQL does not really support altering a view as atomic operation.
Thus, the implementation needs to a) drop the view b) re-create it with a new
statement c) re-create it with the original statement if the second step failed.

This approach is prone to racing conditions. For instance, imagine a second
instance removes the table which the view is based on, just after step a), but
before step c). In this case, to the user the attempt to alter the view will
result in the loss of the view.

We should implement the support for
  ALTER VIEW <name> TO <statement>
in HSQLDB.
Comment 1 Frank Schönheit 2007-09-17 13:38:35 UTC
This is what Fred Toussi, maintainer of HSQLDB, suggested in private mail how
this could be implemented in HSQL:
I suggest the following strategy:

1. check the view is not referenced by any other view
2. create the view with a new name in the same schema (perhaps use a name 
that is illegal for users, e.g. a digit, so that there is no name conflict).
3. if the new view is created, then drop the old one and rename the new one 
to the old name
4. When you have developed the above, you can attempt a more ambitious 
strategy to deal with referenced views too, which means skipping (1), 
renaming the old view to another number in (3) The new view should be 
inserted in the view list just after the old one (the order of view creation 
is critical), then recompiling all views, and if it is successful, removing 
the old view (otherwise remove the new one and rename the old one to its 
original name.
Comment 2 Marcus 2017-05-20 10:44:24 UTC
Reset the assignee to the default "issues@openoffice.apache.org".