Re: [GSoC][Patch] Automatic Mode Detection V1

Do you want me to ask our design guy for an icon?

That would be great to keep things clear and separated for the users.

Please find attached a patch to fix the problem that happened with you. The problem is that I edited the primary_keys.sql file in web/tools/sqleditor/templates/sqleditor/sql/default/ only, while there was another one in ..../templates/sqleditor/sql/11_plus/. I wonder what happens with versions before 11? are the scripts in the default/ folder used if they are not found in that version folder?

The patch also removes a few unnecessary lines of code that I found, not related to the problem.

- What documentations or unit tests should I write? any guidelines here would be appreciated.

We're aiming to add unit tests to give as much coverage as possible, focussing on Jasmine, Python/API and then feature tests in that order (fast -> slow execution, which is important). So we probably want 

- one feature test to do basic end-to-end validation

- Python/API tests to exercise is_query_resultset_updatable, save_changed_data and anything else that seems relevant.

- Jasmine tests to ensure buttons are enabled/disabled as they should be, and that primary key and updatability data is tracked properly (this may not be feasible, but I'd still like it to be investigated and justified if not).

We're also a day or two away from committing a new test suite for exercising CRUD operations and the resulting reverse engineered SQL; if we can utilise that to test primary_keys.sql, that'd be good.

I am sorry but I don't understand what should be done exactly in those tests. Could you tell me where I can look at examples for feature tests, Python/API tests and Jasmine tests (preferably for features related to the query tool)?

 

Once the in-place editing works, we'll need to rip out all the code related to the View/Edit data mode of the query tool. For example, there will be no need to have the Filter/Sort options any more as the user can edit the SQL directly (that one may be controversial - it's probably worth polling the users first). Of course, if they don't want it to be removed, we'll need to re-think how it works as then we'd have a dialogue that tries to edit arbitrary SQL strings.

I think it makes more sense for filters to be disabled. I mean since the user is already writing SQL it would be more convenient to just edit it directly.