GSoC 2017 - Week 7

It’s Eid eve, and finally, I’ve recovered from viral fever after more than 2 weeks. The feeling of weakness and quick fatigue has subsided after a very long time. Now I’m feeling good and I hope to work with more devotion. Though the temperature in New Delhi is still crossing over 40 degrees Celsius, making everyone uneasy at their work (and rest as well :P).

In this blog post, I would be sharing my debugging journey and how the progress from the first patch became a bug.

Last week, I had submitted a patch for creating hierarchy structure table (T1 from the spreadsheet document) for Cargo Extension. The task was to create and populate table T1, whenever a hierarchy field is saved in a template and “Recreate Data” operation is performed.

To populate the table T1, the following was the flow control:

  1. The user must create a hierarchy field in the Cargo declare command within the template definition.
  2. Saving the template, calls CargoFieldDescription::newFromString() to generate several Cargo Field Description objects which are then saved into the database as blobs, using CargoFieldDescription::toDBArray().
  3. Performing the operation “Recreate Data”, creates table T1, T2 and T3 (if required) and adds a Job into the queue to populate original Cargo tables (T2).

Specifying “Hierarchy” in Cargo Declare Specifying "Hierarchy" in Cargo Declare

Creating a form (Page Form automatically detects tree as default type for hierarchy) Creating a form (Page Form automatically detects tree as default type for hierarchy)

Filling the form Filling the form

Created Page Created Page

Hierarchy Information in Nested Set Model Hierarchy Information in Nested Set Model

The patch worked as expected as it was focussed on populating T1. But as soon as I had submitted the patch I realised that original Cargo table T2 was being populated but the column with depicting the hierarchy field was NULL.

Table T2 being populated, but the hierarchy field is NULL Table T2 being populated, but the hierarchy field is NULL

Here came the biggest challenge of the week, about finding the bug that was preventing the job to populate T2 with hierarchy field data in “_value”.

The main challenge for a beginner is to find the relevant piece of code in the ocean of functions and files of the codebase. I strived to dig up the portion responsible for populating the data into the table T2. But eventually, I got blocked and required help from my mentor. Yaron told me exactly what to find - that is - find the portion of code responsible for “actual insertion of data into rows”. After his advice, I realised that I wasn’t looking for the right piece of code and that too with the improper keyword.

Tip: When you have to find a relevant function or piece of code, try to search in the project with the keywords of SQL query (as in my case), or the variable names (like “ = $var” or “$var = “ can help you filter down) or function calls. All though this might look very naive, till now I have got so far :/

Using the right keyword “insert”, I easily found my relevant code.

Now, comes the part when I realised that my own decision in the very first patch has become the root cause of the bug. During the start of the project, I have added the functionality to detect the hierarchy keyword and extract hierarchy structure from Cargo Declare statement in the wikitext definition. At that point, I decided to store the hierarchy structure (“” formatted structure) in the $mAllowedValues[0] of the class CargoFieldDescription. And this action caused a bug in the allowed values check, which iterates over all values of a list to ensure that each value given by the user exists in the $mAllowedValues array. Since I had messed up the structure in which $mAllowedValues was to store the information, now that check could not pass any of the values as $mAllowedValues had a single element - a string with multiple “” and supposed allowed values, all together in a single string. Obviously, a string of all allowed values separated by “*” can never be equal to a single value, even if that single value is in the supposed allowed values.

After discussion with Yaron, we decided to add $mHierarchyStructure to both the classes - CargoFieldDescription and PF_TemplateField.


  • Do not try to fit a property into other, for which it is not meant.
  • Do be scared to modify code in order to preserve the organised structure (if you don’t do that, you will end up creating a mess)

Later this week, I incorporated code reviews in Page Forms and Cargo branches and uploaded the patches. ( PF - hierarchy-project, Cargo - hierarchy-populate-tables )

comments powered by Disqus