After receiving the Vagrant file, the team was excited to finally be able to setup a development environment that closely emulated the production server. After resolving an issue with the local tests, the team launched into doing some planning for our first feature. Our first feature involved making changes to allow Eratosthenes to hold more than one version of a library. Currently, Eratosthenes can only hold one version of a library (usually the latest one) and while it had worked in the past, there seem to be demand for Eratosthenes to be able to hold more than one version of a library. After much discussion, the team agreed on the following proposal:
Firstly, we need to make changes to the database to allow it to hold different versions of a library. We intend to do this by creating a new table named `versions` that would contain 4 columns: (1) id - the unique ID of that entry, (2) ExternalLibrary_id - a foreign key that points to an ExternalLibrary in the ExternalLibrary table, (3) version - the version number of that entry and (4) source_url - the URL of a specific version of the library file that is to be shifted from the ExternalLibrary table to the new versions table. This updated schema will allow us to hold different versions of a library without duplicating information in the database.
Then, we also agreed that the forms, controllers and routes have to be modified/added accordingly to cater to requests for a specific version of a library.
Next, we pondered over the question of how the existing CodeBender IDE/compiler needs to be modified in order for it to be able to serve the correct version of the library that the user is requesting. For this, we came up with 3 options but we think that the last option is the most feasible one - that is, the user will specify the library version in the name of the library (e.g. include "datetime-1.3.h") and when our controller receives this request, it will parse the library name accordingly, splitting the name at the dash to retrieve both the library name and the library version number. If no library version number is specified, then we automatically fetch the latest version of the library. This solution seems to be the cleanest out of the 3.
We also thought of ideas on how we should convey the versions available for a particular library to the users. For this, we agreed that we might have to modify the frontend of the CodeBender application in order to list the supported version numbers with the library description.
Last but not least, we thought that we should create a user guide for this feature so that users will know how to specify the correct library name to fetch the correct versions of the library.
One thing that we might have missed out though, is the creation/modification of automated tests to ensure that our feature is covered by tests. In our follow-up discussions online, we agreed that we will need to create and modify the existing tests in order to make sure that our new features work and the old features are likewise preserved.
That is our discussion in a nutshell.
Firstly, we need to make changes to the database to allow it to hold different versions of a library. We intend to do this by creating a new table named `versions` that would contain 4 columns: (1) id - the unique ID of that entry, (2) ExternalLibrary_id - a foreign key that points to an ExternalLibrary in the ExternalLibrary table, (3) version - the version number of that entry and (4) source_url - the URL of a specific version of the library file that is to be shifted from the ExternalLibrary table to the new versions table. This updated schema will allow us to hold different versions of a library without duplicating information in the database.
Then, we also agreed that the forms, controllers and routes have to be modified/added accordingly to cater to requests for a specific version of a library.
Next, we pondered over the question of how the existing CodeBender IDE/compiler needs to be modified in order for it to be able to serve the correct version of the library that the user is requesting. For this, we came up with 3 options but we think that the last option is the most feasible one - that is, the user will specify the library version in the name of the library (e.g. include "datetime-1.3.h") and when our controller receives this request, it will parse the library name accordingly, splitting the name at the dash to retrieve both the library name and the library version number. If no library version number is specified, then we automatically fetch the latest version of the library. This solution seems to be the cleanest out of the 3.
We also thought of ideas on how we should convey the versions available for a particular library to the users. For this, we agreed that we might have to modify the frontend of the CodeBender application in order to list the supported version numbers with the library description.
Last but not least, we thought that we should create a user guide for this feature so that users will know how to specify the correct library name to fetch the correct versions of the library.
One thing that we might have missed out though, is the creation/modification of automated tests to ensure that our feature is covered by tests. In our follow-up discussions online, we agreed that we will need to create and modify the existing tests in order to make sure that our new features work and the old features are likewise preserved.
That is our discussion in a nutshell.
Comments
Post a Comment