Sixth week report - Export view as it was a table

Sixth week of coding was spent mostly on two tasks. The first one was extending hiding tables in navigation panel to other top level items under a database and polishing up the implementation. There were couple of suggestions by my mentor as well as other phpMyAdmin team members about the wordings and tables names I corrected them in my subsequent commits. The second task for the week was implementing 'rfe #1321 - Export view as it was a table'.

Implementing the new feature I introduced a new checkbox at the export page for the users to specify whether views should be exported as they were tables. This is not checked by default, leading to exporting view definitions as earlier, not to surprise users who are used to the old behavior. Here is a screenshot of it.

To derive a suitable structure for the table I used the output from getColumns() method of DatabaseInterface and the data returned by the method were sufficient to identify the properties of each column of the view.

The feature works at 3 levels
1. Exporting a view using the export tab at table level
2. Exporting the results of a query on a view
3. Exporting rows of a view by selecting the with checkboxes that are displayed against each row.

As indicated in my schedule I plan to use this week to write test cases and documentation for the development carried out in the first iteration. I have updated most of the documentation alongside feature implementation. So documentation would mostly be on updating the wiki.

Fifth week report - Hide/unhide tables in navigation tree

During the fifth week of coding I went on to implement 'Hide/unhide tables in navigation tree' feature. Although I originally planned to start working on it in the fourth week I was unable to do so due to some work carried forward from third week. However I was able to finish off the work and the feature is now ready to be merged after my mentor's inspection.

This feature requires an additional table to the phpMyAdmin database to make the hiding stored permanently. When this table is configured an icon is displayed in front of each table which allows the table to be hidden from the tree. Any database having hidden tables will also have an icon in front of it which allows unhiding hidden tables. Unhiding tables is facilitated in a dialog which is poped up upon clicking the above icon and it shows hidden tables and allow unhiding each of them. Below screenshots illustrates what is described above.

When implementing the feature I had in mind that this could be extended to other items in the navigation tree and designed the feature in such a way. Later I extended the feature to allow hiding/unhiding functions, procedures, events and views.

What I have planned for the sixth week is 'Exporting view as it was a table' feature. After the implementation a user exporting a view would have the choice of choosing between the definition of the view (current implementation) or the data of the view (proposed implementation). If the latter is chosen, the new implementation would derive a suitable table structure (CREATE TABLE statement) as well as insert queries.

Fourth week report - Ajax dialog for editing a view

During the fourth week of coding my main focus was on implementing feature request 1373, which requested to use the same editor creating and altering views. Earlier the SQL editor was used for view altering which did not provide any guidance on the process. So I went on to use the same editor used for view creation for view altering. Further view create/alter editor lacked some features such as fields to define SQL Security and Definer parameters. I have now added these fields to the editor, so the user has the full capability to create/alter a view. Here is a screenshot of view altering editor.

Isaac and Marc had commented about the configurable menus feature I implemented last week. In their comments they had suggested some improvements and I spent the latter half of the week implementing them. Those improvements included a feature to view users of a particular user group, separating user and user group management to separate secondary level tabs. Here is a screenshot of the new look and feel of 'Users' page.

In my schedule I had planned to start working on 'Hide/unhide tables' feature. But this got delayed as I had to work on the configurable menus feature. However this should not be a problem as I have this whole week allocated to completed the feature.

Third week report - Configurable menus

'Configurable menus' feature which I attempted during the third week of GSoC was the biggest I've implemented so far. RFE 316 merely asked for a basic mode in addition to the Advance (what we had earlier) mode. However I decided to implement this in a more generic way where this feature would let the super users configure profiles and assign users to them. These profiles will have limited rights defined and the logged in users would only see specified menus.

Implementation of this feature request includes
1. An interface to add and edit a user group to specify the allowed menu tabs.

 
2. A user group table which shows user groups and menu tabs allowed for each of them grouped in to server, db and table levels. Each of the user groups had links to edit them and delete them.

3. Ability to assign users to user groups when creating users.

 4. Edit user group assignments.

For the next week I have planned to implement 'Ajax dialog for editing a view' feature requested in RFE 1373. Currently editing a view is facilitated inside the SQL editor page while creation of a view is with a nice dialog. I will change the editing procedure to use the same dialog for editing. This would allow changing of options related to the view easily.

I also plan to start some work on feature 'Hide/unhide tables' (RFE 1385) as I feel it would take more than a week.

Second week report - find and replace by column

What I had planned for the second week of coding was the feature named 'Find and replace by column' requested in feature requests #487 and #1405. Reading through the feature requests it is evident that this feature was a quite needed one.

I approached this one by planning the user interface for the feature. I chose 'table search' tab to be the most suited one to include the UI for the new feature. 'Table search' tab already had a second level of tabs for 'ordinary table search' and 'zoom search'. So I added another secondary level tab for the new 'find and replace' feature. The new UI looks like the image below.

The initial UI facilitates entering a phrase to look for and a phrase to replace the original one. The column drop down facilitate choosing the column in which this operation is to be performed. Only the columns which has a text type is listed in the drop down as this operation in not valid for others.

When the user submits the form, having entered the above parameters, a case sensitive search is performed and a preview of replacement to be done is shown. Achieving a case sensitive search was problematic as some collations are case insensitive. However I overcame this hurdle by converting the collation to a case sensitive one in the same character set. Here is a screenshot of the preview.

Upon confirmation the matched string are replaced with the given string.

For the next week I have planned to implement 'Configurable menus' feature requested in #316. What is requested in the RFE is a basic mode with limited features exposed to the user. However, I would like to implement this in a more generic way where this feature would let the admin configure profiles and assign users to them. These profiles will have limited access defined and the logged in users would only see menus related to these features.

First week report - Relation Interface Improvements

I worked on 'Relation Interface Improvements' feature during the first week of GSoC and was able to successfully implement it. Now the cumbersome task of setting relational constraints has been made somewhat easy and is less error-prone. 

 

With the changes the long dropdown to select foreign column has been split to two dropdowns, one to select the foreign table and the other to select the foreign column. I also extended this to support cross database relations with an additional dropdown to select the foreign database for both internal and InnoDB types. Here is what the relation view interface looks like now.

 

 

So, when the user selects the database, the entries in the table dropdown are filtered only to show tables in that database and column dropdown is filtered in a similar manner when a table is selected. Own database is selected by default as it's more common to setup relations inside the same database.

 

Checking relational integrity feature was already supporting cross database relations. I added table name to the displayed text to make it clearer. I also updated a couple of FAQs in the documentation related to these features. 

 

For the next I have planned to implement 'Find and replace by column' feature which is quite long due. I have some preliminary work on it, and plan to finish implementing it during this week.

Coding begins

According to GSOC 2013 timeline, the coding period begins tomorrow. It's quite exiting as we get to do some hands on coding. I have pretty much completed reading documentation and getting myself familiarize with the code. Meanwhile I pulled merge requests for a couple of bugs and those fixes were incorporated to the code.

I am going to implement 'Improve relational view interface' feature during the first week. This is based on feature requests RFE #1283, RFE #1233 and RFE#175 from the feature request tracker. I've done some investigations related to these features during the last week.

With the implementation choosing the foreign column would be made a two step process. First the user chooses the foreign table from the table drop down which would filter the column in the columns drop down accordingly. Hence choosing the correct column would be much easier. Finally, the relational system would be enhanced to support cross database relations. Relational view interface would facilitate adding/editing these relations with an additional drop down to chose the database.

I will use 'relView' branch of my repository to implement this feature. However it is still empty, I will make a commit when the new code is stable.