For this week, I was working on the feature to compute the existing and final quantities of history.<\/p>\n\n\n\n
Started off by coding an algorithm to compute these values, the aim was to design an algorithm with minimal computational complexity. Since in my last meeting with Mr. Peter, I was informed that any changes in database would only be made when all other ways of performing this task return unsuccessful. Therefore, I was left with no other option than to store the data locally. The idea was to store the final quantity of a history quantity which would be the existing quantity of the following history for the same item.<\/p>\n\n\n\n
Created a static class to hold global variables, stored final and initial quantity in a global variable to prevent data being lost on a new API call. Eventually, I was able to design an algorithm which correctly computes each quantity; However, storing data locally meant that the data will be lost when the App restarts. After considering these facts and also the computational cost Mr. Peter instructed me to change my approach and use a database for storing quantities.<\/p>\n\n\n\n
To store the values in the database, I added four new fields to the entity. I override the create method for history entity so that it now populates the new fields based on the logic. Finally, I ran a stock adjustment test to see if the new fields were being filled in.<\/p>\n","protected":false},"excerpt":{"rendered":"
For this week, I was working on the feature to compute the existing and final quantities of history. Started off by coding an algorithm to compute these values, the aim was to design an algorithm with minimal computational complexity. Since in my last meeting with Mr. Peter, I was informed that any changes in database … <\/p>\n