Pre Midterm Evaluation

Hi readers,
It has been a long time since my last post, in fact I have missed the deadline for my first progress update. I am sorry about that. It was because my project was lagging behind the timeline due to some design and it became my first priority to get the project back on track and I was so much busy in doing so that I almost forgot I also have to maintain my blog. As all of us know, coding period phase 1 has come to end. It was a great time involving intense discussions, coding, roadblocks as well as brainstorming and now its time for midterm evaluations.

Discussions:

During this period, I had an intense discussion with Barry. In first week of the coding period, I was working to implement the new IStyle and IStyleManager interface according to my proposal. While implementing the new IStyle interface I felt that in order to ensure that the attributes dictionary passed to the __init__ method contains all the styleable attributes(since previously, I was assuming styles to be a complete set of attributes), I will need to have a list of all the styleable attributes. So I decided to go for code refactoring by moving all the styleable attributes to a new interface 'IStyleable' interface which then can be extended by the existing IMailingList interface and the new IStyle interface. I asked Barry for his permission for this refactoring and he agreed but he also said that it would be good if I make styles composable in terms of small set of attributes(stylets) as the current IStyle interface supports. We then had a long discussion on what would be the behaviors of these new stylets and how can these stylets be used to compose styles. Subsequently, the new design was finalized(I will be explaining the new design in my next blog post) and I got to realize that my original design was having a large number of shortcomings that I would have to face while implementing the REST API and the frontend.

Brainstorming:

Now I needed to devise a mechanism such that if an user updates any stylet or style, then, any mailing list using either the updated style or a style composed of the updated stylet will get updated automatically. For accomplishing this task I was having an option to override the __setattr__ method and trigger a stylet/style updated event whenever this method is called but as this would trigger the event for each and every assignment, an instance managing a large number of stylets/styles would come to its knees within seconds.
After wasting some time in devising some way of solving this problem, I cam to know about SqlAlchemy's mapper level events and after reading their documentation, I decided to use them.

Roadblocks:

Unfortunately, during this period I faced two major roadblocks:
1: During the time of discussion, Barry was busy in PyCon 2016 and was not available on IRC for a real time discussion. So I had to contact him via email which was very time consuming and I was not able to make much progress during that week. But I have to say that in-spite of being busy, Barry tried to answer all of my queries as clearly and as fastly as possible(Thanks to him!).
2: When I was testing the new event system I came to know that even after changing a style/stylet the events aren't getting fired. Then after spending some time in trying to figure out the problem, it came to my notice that if I fire a query after changing a style, the events are fired in proper order. I was unable to figure out any possible reason for this kind of behavior. I found a solution to this problem on stackoverflow. Events in sqlalchemy are fired when a flush occurs and a query causes an auto-flush to be triggered which causes the events to be fired. It took about three days to figure it out and caused a lot of frustration.

Overall it was an amazing experience to see my project taking shape and solving those roadblocks was the most interesting part although it caused some frustration as well but I loved it. Keep connected for more.

Thanks,
Harshit Bansal