Description:
The editor for creating VIEWs currently has functionality where it tries to parse the view and then either makes attempts at reformatting the view or (in some scenarios) deleting some-or-all of the CREATE VIEW statement if it finds a problem with it.
The "how to reproduce" below describes a specific scenario I have just tripped over (and also a workaround I am using for now) but I think this is a wider problem that needs addressing.
The overall issue I have is that WB probably shouldn't "pull the carpet from under the user's feet" while they are still in a text editor. I can appreciate the usefulness of functionality that tries to correct mistakes and keep the view valid but where this functionality performs its checks aggressively - mid-editing - it causes rather a lot of frustration.
How to repeat:
* Create a new model & diagram
* Place a new view and write a short SELECT statement such as '1, 2, 3 FROM DUAL'
* Highlight the text of the view and right-click » Copy
* Place a second view on the diagram and double-click to edit it
* Highlight all of the text in this view and right-click » Paste
* A split second later, all of the text you pasted in is clobbered - I assume because WB determines that the two views cannot have the same name
In my specific use-case I was trying to create a view that was similar to an existing view, hence beginning with a copypaste. The view text all got deleted before I had a chance to go and make the modifications (such as giving the second view a unique name) though.
My workaround for now is to begin by copy-pasting the view in the model itself which creates a view named `some_view_copy1` and this copy seems immune from being clobbered. I can then edit that to get what I wanted.
Suggested fix:
In my honest opinion I don't think that the 'parse the view and fix it for you' functionality should ever fire unless explicitly requested by the user. Any time when it makes a run over the CREATE VIEW statement when not requested explicitly can cause unexpected results and be quite disorienting for the user experience.
This functionality could remain, but instead maybe break into two parts:
* A parsing run that checks whether the VIEW code is valid (I believe this is already done, since a blue or red marker indicates whether it is valid at the moment, so there must be some kind of "valid" or "invalid" state that can be checked)
* A small control button (placed near the view text editor) labelled "attempt auto-fix" or something like that. This button would be disabled if the view is valid. Clicking this performs the attempted rewrite of the view code.
This way any time the view code is changed by WB, it is because the user asked WB to try and fix it.
