Last week I somewhat improved my implementation of jqplot porting for status tab. Earlier the page could hold only one chart at a time, means that if a user switched among tabs on the status page while a live chart was on progress, when switching back to the same tab the chart was no more there. It had to be, as jqplot should know the dimensions of the target div to plot the chart, which became unavailable on switching to some other tab. Now after I did a chart replot on tab showing up again, the chart starts again. So multiple charts can now resume on switching tabs.
Also, I started migrating the status => monitor tab to jqplot.
This week I continued working on highcharts to jqplot migration of Status page charts. Main ask accomplished was the migration of live traffic chart and live connections/processes chart to jqplot. Live Queries chart was already migrated to jqplot in the last week.
The new jqplot live charts like highcharts, are customizable for refresh rate, also I have added a customization for the number of data points visible at one time using select list.
Under Status page, there are several tabs of which Server and Traffic have charts plotted using jqplot. In an event of switching between these tabs when the live charts are running under both tabs, I noticed some misbehaviour and jqplot seemed to shorten the width of the charts to half their original width. So, the next task is to make multiple charts work properly at the same time.
This week I started working on highcharts to jqplot migration of live query statistics chart (Status => Query Statistics => Live Query Chart). Initially, we were facing a problem with jqplot’s dateAxisRenderer plugin, that it crashed when plotting a chart with very small time intervals. But a fix provided on  solved the problem, though the fix is not a part of official jqplot release yet.
The next problem was to make the live chart move to left with time, initially I tried to make that work by shifting the data values in the array provided as data to jqplot as in . It produced the moving effect to some extent but was not as seamless as highcharts. Also the number of data points on x-axis kept fluctuating making it hard to read the chart.
So in  I tried moving the chart to left by tweaking the min/max values of charts’ x-axis on every replot. Now the live chart seems to be more viewable, also it gets easily re-adjusted on refresh-rate change.
This week I planned to work on the InnoDB relations support feature for db_qbe search. Though I couldn’t come up with some committed progress towards the feature’s implementation, but I studied closely how LEFT JOIN creation currently happens in case of PMA’s internally defined relations. And I tried to make myself understand what exactly needs to be done to integrate InnoDB relations.
Currently, LEFT JOIN generation procedure involves following order in libraries/DBQbe.lib.php:-
=> _getIndexes() // provides us which tables have UNIQUE and INDEX columns and which are with/without valid where clauses
=> _getLeftJoinColumnCandidates() // provides us with best possible table.columns based on UNIQUE, INDEX, with/without valid where clause info
=> _getMasterTable() // provides master table for LEFT JOIN from table.column candidates (smallest based on records count)
=> _getFromClause() // sets from_clause = master_table + PMA_getRelatives(all_tables, master_table)
=> PMA_getRelatives() // looks for master->foreign and foreign->master entries in PMA internal relations table and generates LEFT JOIN clause.
So, only PMA_getRelatives finally looks for PMA’s internal relations and before that we just try to find out the best master table. So while thinking about introducing InnoDB relations into this flow, I still need to ascertain whether the same master table is to be used in case of InnoDB relations too and also I need to decide how to use PMA_getForeigners() (that provides us InnoDB foreign relation details for a table) in PMA_getRelatives().
And as it was taking too much time for now, I have currently moved on to PMA’s ‘highcharts‘ to ‘jqplot‘ migration and I’ll get back to InnoDB feature later.
This week I continued refactoring in db_qbe.php. A new class PMA_DbQbe was created to accommodate the db_qbe functionality, and db_qbe.php now creates a new instance of PMA_DbQbe to execute all qbe related operations. About functionality, it seems almost unaltered to me as of now, after fixing a few introduced bugs reported by Marc. I am happy that the refactoring on schedule is complete except testing, and I will continue testing the refactored code to fix any other bugs.
As of now, database qbe search only supports ‘PMA internal relations‘ for creating LEFT JOINS automatically in case of related tables. I plan to introduce InnoDB relations into QBE search as suggested by Marc. The InnoDB relations data is already available but the main task is to use it in relation.lib.php(PMA_getRelatives) to somehow create LEFT JOINS out of it.
This week saw the conversion of search scripts to object-oriented style. A new class PMA_TableSearch has been formed to accommodate all table search functionalities. The PMA_TableSearch class can be instantiated for normal as well as zoom search, public method getSelectionForm() is then used to display the respective search form. Similarly after the form submission, buildSqlQuery() is used to generate SQL query for execution.
In case of zoom search(as it doesn’t use AJAX to fetch plot), the previously submitted form data is displayed using getColumnProperties() method. This public method is also used to update column information in zoom search column-select list. Another public method getZoomResultsForm() is used to display the zoom search results form. Apart from above mentioned publicly used methods, several other private methods that were formed during last weeks, now form part of the PMA_TableSearch class.
As of now, the scripts tbl_select.php and tbl_zoom_select.php appear to be quite cleaned up of unreadable code and are quite readable now. Previously used library file tbl_select.lib.php has been replaced with TableSearch.class.php. Moving on, next week I plan to take up db_search.php, also suggestive improvements will be done in PMA_TableSearch.
The third week of my GSoC project has ended now. This week invloved many major improvements in zoom-search script. The part of script responsible for displaying zoom-search selection form has been fully accommodated with that of normal-search, after some generalizing changes in responsible functions. Now both types of search forms are displayed using PMA_tblSearchGetSelectionForm().
The following new functions were also formed :-
- PMA_tblSearchGetRowsZoom() /* Returns HTML for displaying zoom search selection form. */
- PMA_tblSearchGetOptionsZoom() /* Returns extra search options i.e. datalabel and maxrowplot limit. */
PMA_tblSearchGetCriteriaInput() /* Returned already set criteria inputs but later it was no longer needed. */
- PMA_tblSearchGetColumnProperties() /* Provides column’s type, collation, operators and input area. It removes the need to set these column properties separately every time. Also it takes care of any already set criteria input. */
Other improvements involved removal and improvement of some repetitive code in tbl_zoom_select.php, removal of some useless variables and fixing of some newly introduced minor bugs.
During my second week of GSoC, I moved the newly formed “table search form” producing functions and “SQL query execution” functions to the library file tbl_select.lib.php. A major improvement that followed was the use of $_POST where post parameters were to be used in functions PMA_tblSearchBuildSqlQuery() and PMA_tblSearchGenerateWhereClause(), to explicitly signify the use of post parameters. This improvement helped reduce the post_params array in tbl_select.php to minimum size. Also, the variable names across search scripts were made same and more logical.
Then, refactoring was initiated in tbl_zoom_select.php, in which I started with fixing a couple of bugs related to zoom search form display. After that, I started generalizing the previously formed functions to accommodate zoom search in them. It involved slicing of some new functions namely :-
As a result, it is intended to use the functions for normal search and zoom search in expected ways. It was followed by the use of some of these functions in tbl_zoom_select.php and next week would also involve further improvements in tbl_zoom_select.php.
I started working on my GSoC project on around 14th May. Initially I have taken up the script ‘tbl_select.php’ which is responsible for the Table Search feature of phpMyAdmin, means it lets the user execute all types of ‘SELECT’ queries on the table with the help of an intuitive UI. I started with a rough plan to first convert the code in ‘tbl_select.php’ to functional style which would be followed by moving the newly formed functions to the script’s library file ‘libraries/tbl_select.lib.php’. The following new functions have been formed :-
Apart from this, various variable name and other improvements have also been done. As a result, the HTML-PHP tag mixture previously present in the script has been replaced with clean, understandable, functional PHP code :). And about ’libraries/tbl_select.lib.php’, I have planned to convert it into a class file after inclusion of newly formed functions from ‘tbl_select.php’ and ‘tbl_zoom_select.php’ into it.
Work done can be found at my phpMyAdmin fork on github :- https://github.com/zixtor
My project proposal to phpMyAdmin has been accepted for this year’s Google Summer of Code :). Around 10 students got selected for GSoC from my college this year. Marc Delisle, project administrator at phpMyAdmin would be mentoring me throughout the project.
GSoC is a Google’s initiative to encourage students to contribute to Open Source Projects, though one can contribute to an open source project anytime of the year provided some awareness and enthusiasm and coding is not the only way to contribute. We can always contribute by reporting encountered bugs, writing documentation, making video tutorials to help users, designing themes/logos and of course by Donating. But yeah! its more exciting to do so by coding and also getting sponsored by Google :).
Starting next month, I would work on the project as described in the proposal. Until then, it is Community Bonding Period, so I would get to know the community and my mentor and I would discuss the project implementation details.
Below are some links about the project:-
Project Git Branch: https://github.com/zixtor/phpmyadmin/
Project Demo: http://demo.phpmyadmin.net/gsoc-atul