RandomTannenbaum
commented
5 months ago Stand 28.06.2024 Was mir noch aufgefallen ist:
- Momentan bekommen wir von der API scheinbar auch EX-Members. Die API gibt uns jedoch nichts, anhand dessen wir wissen könnten, ob es sich bei den Daten um einen solchigen handelt. Das bedeutet, dass momentan für jeden EX-Member, der im Skills kein Profil hat, ein neues, ungenutztes Profil erstellt werden würde.
- Wir bekommen von der API einige Felder nicht, die auf dem Model obligatorisch sind, für welche ich momentan beim neu Erstellen einfach einen default-value gesetzt habe. Namentlich sind dies:
skills_person.company = Company.first skills_person.birthdate = '1.1.2000' skills_person.location = 'Bern' skills_person.nationality = 'CH'
Bezüglich des jobs habe ich es lokal mal mit einem Cron-Job ausprobiert. Im Gegensatz zu Delayed-Jobs, welche database-based sind, laufen Cron-Jobs direkt auf dem Betriebssystem. Cron-Jobs kann man manuell erstellen, indem man mit crontab -e das crontab file bearbeitet. Darin kann man eine Zeitangabe und den auszuführenden command.
Hier ein kleiner guide.
Noch einfacher geht es mit dem gem whenever, was ich auch lokal ausprobiert habe und was sehr gut funktioniert hat. Whenever hat ein config file in dem man mit einfacher Syntax Cron-Jobs definieren kann. Das könnte in unserem Fall so aussehen:
every :day, at: '12am' do
rake "ptime:update_people"
endDie Jobs können dann mit whenever --update-crontab automatisch im crontab-file des Betriebssystems registriert werden. Mit whenever -c können diese auch wieder entfernt werden.
Desweiteren kann man zum Beispiel auch log files definieren, in denen der output der Cron-Jobs geloggt wird.
Ansätze 01.07.2024
- Bezüglich EX-Members: Die Einfachste Lösung wäre die Members von Hand herauszulöschen falls keine bessere Lösung gefunden werden kann.
- Nicht alle obligatorische Felder vorhanden: Eine PR auf das PuzzleTime stellen und die wichtigen Felder in der API ergänzen.
Introduction Since we will be using data from the PuzzleTime API, we need to make sure that this data is up to date. This isssue here is a suggestion how it could be solved. The idea consists of a nightly job that runs every day (or night I guess) which fetches the data of the PuzzleTime API.
This data would then be mapped into our persons and following keep the persons up to date. These changes will result in PuzzleTime becoming the source of truth in the dedicated person details.
Things to consider Handle the update and creating of people correctly. Which means Members need to have some kind of id, so they get updated correctly. This should already have been done in #735 This id prevents the job from creating a new member with the same name but different user data. It also prevents the job from creating a new person when someone is getting renamed (like married as an example). If a new member is added the delayed_job recognizes that and creates a new profile in PuzzleSkills.
ToDo