Closed lukaszmichalskii closed 2 years ago
Ok, I think I know what you meant with that F1APIJobExecutor
. You wanted to use that in the future to persist fetched data with Repository classes, right? I think we don't need to fetch data every time we want to run spring. I think that script that would convert fetched data to sql would be better but as I said I don't think is is something we should be working on right now
Yep, by F1APIJobExecutor I mean updating/validating data in the future, for now, it is PoC (proof of concept) of such a feature. Further, when API will be ready this feature is essential because of one requirement needed in Software Engineering classes. It might work like some kind of button "Update data" by clicking it will check if everything is up to date and if not prompt to update data
- Did you test this? Did it work for you? I have my local database instance running on docker. Tested it yesterday with crucial (bare) SQL queries in docker terminal and so far everything was working.
Ok, then I think we should wait until repositories are ready and put it into spring application, not as a separate executable. How about leaving F1APIJobExecutor.java
on separate branch and not merging it for now. We would merge docker and .sql
file in this PR. Do you agree?
When I execute all queries from init.sql
file on the existing tables made from JPA I get errors about some constrains:
I will check this issue one more time with the master then cherry-pick docker-compose.yml configurations and the .sql
initialization script. For now abandon F1JobExecutor feature, as clarified first we need to create a complete working API.
Prototype of F1API service for updating database automatically without interfering with our system API. For now, used for manual testing and creating an initialization script to the database (see: init.sql file).
From my investigations, it seems to be a pretty big task, blocked by API CRUD features not implemented yet. But still maybe you want to have such prototype in our main repo