Closed lex-lex closed 5 years ago
I agree that keeping asking the user to save is not a good idea. I think that some kind of auto saving would work ok.
One solution to the second problem can be to save the previous state in the db and have a button 'revert' which allows to revert to this state
One solution to the second problem can be to save the previous state in the db and have a button 'revert' which allows to revert to this state
I don't think that this will work. I often add conjuncts C1, execute, add cunjuncts C2, execute, etc. and then close the document without saving (to have all the conjuncts not saved). This will not really work with reverting (unless you want to keep a lot of states).
As a first step, I think just auto saving is ok. We can change that later on, if necessary. Do you agree?
Currently, queries (and consistency checks) are executed via a call to the back-end that specifies the id of the query (or the normalization). As a consequence, only queries that have been saved to the back-end can be executed. Also, more importantly, if I open a query, change it and hit the "execute" button it will actually not execute the query that is displayed in the front-end but the version that is currently stored in the back-end. This can confuse people into thinking that the displayed result applies to the content of the GUI while it actually refers to an (invisible) old version.
This situation is really bad. Using the current architecture (submitting the id of the query only for execution), I see two options:
I'd favor the first option (less annoying).
However, I see a flaw in the base concept of submitting an id (i.e. having to save a query first in order to execute it): When I do experiments, I usually change small things very often and see what happens for each change. That does not imply that I want to keep these changes; in contrast, I often want the original state afterwards. This is not possible here (this would require sending the query itself and not an id).
Opinions?