If we implement #138 as the way to keep in memory our models before we output to the final representation (the file representation of YGOJSON), the back and forth conversion between the fetched data and the final model would pass always through the DB model. This means that there would be unnecessary transfer of data between models without any value.
A better option is to drive the application by using our DB-entities instead as the driver of the application:
Fetched data is converted into our DB-entities
This DB-entities could be save directly
The DB-entities can be requested and updated by using the other data sources (future development)
No intermediate layer of our models would be required.
This means that we will keep the output layer completely detached from the fetch layer, with the DB in the middle to be the translation point. This makes more sense because most likely the cron-job will operate over entities that might have extra information that we don't want in the final models (i.e., unique-ID that is independent of the maybe missing UUID v5 that is consistent between runs from scratch).
Nevertheless, this also means that if we want to have the DB as the driver, this DB-entities might not be the right ones to create the DB-format outputs (but that will also be the case anyway). First we need to decide if we want that and then see if it makes sense with the current design (still private).
If we implement #138 as the way to keep in memory our models before we output to the final representation (the file representation of YGOJSON), the back and forth conversion between the fetched data and the final model would pass always through the DB model. This means that there would be unnecessary transfer of data between models without any value.
A better option is to drive the application by using our DB-entities instead as the driver of the application:
This means that we will keep the output layer completely detached from the fetch layer, with the DB in the middle to be the translation point. This makes more sense because most likely the cron-job will operate over entities that might have extra information that we don't want in the final models (i.e., unique-ID that is independent of the maybe missing UUID v5 that is consistent between runs from scratch).
Nevertheless, this also means that if we want to have the DB as the driver, this DB-entities might not be the right ones to create the DB-format outputs (but that will also be the case anyway). First we need to decide if we want that and then see if it makes sense with the current design (still private).