GSoC 2015 : Weekly Report #3 : RFE #701 & RFE#726

Week #3

Task(s) completed: None

Task(s) worked upon:
RFE #701 : ‘Print View’ using CSS. (Near completion)

RFE #726 : Batch changing collation of each column in a table (Decision phase)

Scheduled Deadline: 21st  June, 2015

Completed on: NA

Details:

1. The RFE#701 mentions that we should rewrite the ‘Print View’ feature using pure CSS.

CSS(Cascading Stylesheets) (esp. CSS3) has an interesting feature named ‘media queries‘. These are used to make the stylesheets dynamic on the basis of where and how the webpage is viewed. Such queries are generally used in making the webpage responsive (i.e. webpage adjusts itself so that it can be viewed perfectly on any size/type of screen)

We already have a print.css which uses this features while using the features like ‘Print View’, ‘Data Dictionary’ etc. But, currently the Print View operation opens a new tab (using target attribute of a link), queries the table/db data and prints out a well-formatted output on that tab with a small ‘Print’ button which just calls the ‘printPage()’ function defined in js/functions.js

In this complete rewrite, we removed the part of querying the table/db data (since we already have the requried data on tbl_structure.php, db_structure.php, sql.php etc.). Now we added a new file named ‘printview.css’ which was included in all the page-loads but it had properties defined only for ‘printing’. This was done using :

@media print { .../* CSS Properties defined */ }

Now, we added a class property for .print_ignore { display:none; }

But since this property was to be applied only when ‘printing’, we could add this class to all the elements, which we did not want to be printed, while printing them. This required a lot of additions ranging over many different files but result was sweet (:P)

This resulted in files like tbl_printview.php and db_printview.php and their library files and all the templates that Zhang had just written in templates/printview/(I am sorry Zhang) rendered redundant and were removed.

Also, to add a small note, I had started to work upon this feature in a different way[0] but soon realised that the CSS way was quite better than the way I had thought of, thanks to my mentor, Isaac.

2. The RFE #726 mentions that we should provide an added option of ‘Change collations of all Columns of a table’ while changing the default collation of the table in tbl_operations.php.

MySQL Documentation at [1] mentions that this is achieved by running the query :

ALTER TABLE tbl_name CONVERT TO CHARACTER SET charset_name [COLLATE collation_name];

So, I added a checkbox labelled ‘Change all column collations‘ below the collation select box in Table options form on tbl_opertations.php. If checked, this runs the query mentioned above for the given table and selected collation.

Through the implementation of RFE#946 about which I had posted[2] last week, we made sure that if the user data gets corrupted after he/she changes the collation for a particular collation (of course after we have warned him/her before changing), he/she can always get back the data by changing back to the old collation. But, such a thing is not possible here. Since MySQL maps the data from old collation to new, we may not be able to get back the original user data after corruption even if changed back to original collation.

Therefore I added a warning message saying :

This operation uses ALTER TABLE to convert columns from one character set to another and MySQL attempts to map the data values. If the character sets are incompatible, there may be data loss and this lost data may NOT be recoverable simply by changing back the column collation(s).

Are you sure you wish to change all the column collations and convert the data?

Currently, Isaac feels that there might be another way to include this feature and he is currently reviewing that. So, we are still on the decision about the implementation of the feature.

Pull Requests :

1. RFE#701 – [3], [4] (closed due to merging issues) and 2. RFE#726 – [5]

Screenshots : Will post once the features are merged.

Links :
[0]: https://github.com/phpmyadmin/phpmyadmin/pull/1697
[1]: https://dev.mysql.com/doc/refman/5.6/en/charset-column.html
[2]: GSoC 2015 : Weekly Report 2 : RFE#657 & RFE#946
[3]: https://github.com/phpmyadmin/phpmyadmin/pull/1708
[4]: https://github.com/phpmyadmin/phpmyadmin/pull/1701
[5]: https://github.com/phpmyadmin/phpmyadmin/pull/1699

Key Tasks stalled: RFE#701 (got stalled due to crucial decision on implementation), RFE#946 (Still in decision phase)

Tasks for upcoming week: Completing these 2 RFEs and then working on RFE#1359

Advertisements

About Deven Bansod

I am a recent graduate with a dual degree in B.E.(Hons.) Computer Science Engg. and M.Sc.(Hons.) Economics from BITS Pilani, Pilani (India). I am interested in and have been contributing to development of free and open source software s (FOSS). More recently, I have been contributing to phpMyAdmin, a web interface to MySQL, written in PHP. I'm looking for opportunities to contribute to interesting open-source softwares.

Posted on June 1, 2015, in GSoC 2015, phpMyAdmin, Weekly Reports and tagged , , , . Bookmark the permalink. 2 Comments.

  1. A nice summary of your work this week. Good work on the print view, and I like that you are continuing the think about and work on the previous task (changing collations) even though your initial pull request was merged.

    Like

  1. Pingback: GSoC 2015 : Weekly Report #4 : RFE #701, #RFE1359 & RFE#726 | Think and Code !

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: