Fever sucks, I have been taking meds since last week. Now the fever has subsided but still feeling weak. But he (“fever”) cannot stop me from working on such a brilliant Wikimedia project.
Last week, I worked on the spreadsheet document to cover the performance of both the implementation models for hierarchy data for our usecase.
We finalised the column and table names for the hierarchy tables. This discussion was much more extensive than what I had thought. I realized, that the correct naming of entities is very important in a software which is going to be used by many and also bring developed by many. Mentors helped me to improve the spreadsheet document from time to time by reviewing the queries and the expected time complexities. Now I believe the spreadsheet will serve as a lookup guide during the hierarchy database implementation. Mr Yaron asked me to change the foreign key from “id” to the string of the field _value, as this will make it easier to integrate with an already existing design. So I tried to investigate any possible negative impact. To have an external opinion, I also discussed the matter with my classmate, Bhaskar Goyal. After discussing all the implementation, I finalised what microtasks must be included in the next patch:
- Create table - T_1
- Ensure tables - T2 and T3 are generated with correct table name and field name.
- Create HierarchyTree class [Now renamed as CargoHierarchy class] - that would have methods in order to facilitate operations with hierarchy tree.
- Populate T_1
- Test ‘Recreate Data’ for several types of fieldTable creation code added.
At the end of the week, I pushed the patch (hierarchy-create-tables) that fulfilled above points.
Final Output as generation of T1, with hierarchy data represented in Nested Model
comments powered by Disqus