Start the server with default languages.

[Kabongosalomon]

The service starts with no language in memory, and we need to run curl --request GET 'http://127.0.0.1:5000/update to load the language pairs available in the database python manage.py all_languages in memory.

Edit the class AddResource to have default mode loaded when the command docker-compose up -d

[lastrucci01]

I have managed to load a language on the startup on the application

• It involves running the add_language cli command in the Docker entrypoint.sh file
• Then I added a get request in the client to http://localhost:5000/update
• Edited def add_language: db.add -> db.merge

In order to load a default language, we need a way to load the model info into the db (if not already there) then we can call the /update endpoint, but most of the methods I've been trying run into problems.

[vukosim]

Thoughts @Kabongosalomon ?

[lastrucci01]

Hey @vukosim @Kabongosalomon, just some more info on this issue before it is (hopefully) closed.

---

Summary:

• Can I close PR start the app with English to Swahili added to the language table #63 as it is not the solution we ended up using
• This issue can be closed pending merging of PR 🔥 👽️ ✨ (Client/Server): Major updates to system #70
• A good next issue could be creating an update command for manage.py so the model can be downloaded independently of the client

---

To add a default model, we just need to load the model info into database, from there a get req to /update will download the model.

The initial idea is to add the default model into the db from the src/core init.py which was attempted in PR #63, which I think can be closed without merging due to the problems encountered:

• The init.py seems to turn the core directory into a module so whenever another file imports anything from core it will execute the init.py again, this is problematic because if we try load a default model from init.py we will be trying several times on app startup.
• The scripts mainly interacting with the db are init.py and manage.py - and python manage.py run is the command to initialise the server, but db code can't can't be written for manage.py startup because the database is not initialised at that point.

In the docker entrypoint.sh there is a script that waits for the database to start, then it executes the command python manage.py create_db which is a function that creates all the database tables for use.

This was the reasoning to add a python manage.py add_language command in the entrypoint.sh to load default model info into the db - this is now in PR

 #70

A good next issue might be invoking the update command from the python manage.py instead of through the api, then the model can be downloaded independent of a get req to the client.

[Kabongosalomon]

Hi @lastrucci01 thanks for the excellent description of the current solution.

Ideally, I would like us to get rid of the need to hit the update endpoint to have the model available in memory, the current solution works just fine but only loads the model in the database.

The other related issue (maybe we need to create a separate issue for this) is the behaviors of the update endpoints when the db has more than 5 languages, the hit timeout and no model are loaded.

[lastrucci01]

Hello @Kabongosalomon, thanks for the response

I was trying to create an update command in manage.py to replace the update endpoint and I managed to download missing models but the /translate endpoint cannot see the newly downloaded models.

Problem:
In core/init.py we init the api with a function that accepts 'saved_models'
However this param seems to always be an empty dictionary:

So then the api resources are constructed with an empty saved_models assigned to a local variable, the requests made to that resource update the local variable - for example in the AddResouce(/update):

So I think the confusion arises in AddResource when we update self.models, afterwards the TranslateResource calls it's own self.models which seems to be from AddResource despite being two separate classes, I don't understand this behaviour.

A solution might be to have a global saved_models object that manage.py can interact with as well.