We should create JPA models to store in a DB (in-memory) the scrapping and update process of our models; the access-layer would use the repository pattern (with Quarkus Panache). The entities to consider at the moment should be:
[x] CardEntity + CardRepository
[x] SetEntity + SetRepository
[ ] PrintEntity + PrintRepository
We should keep the models simple and evolve from there as at the moment this will be only an internal representation. This means that the only relations would be between cards and sets through the prints. Evolution of this models for more efficiency (and even use as an output eventually) would happen later (we should open tickets for that).
We should decide as we implement if we want to keep a different ID for those models as our UUID might not be present (this problem is highlighted in #5, as unreleased objects might not have an UUID, or will have it changed).
We will use sqlite for the in-memory DB, as it will also allow to eventually have a file dump to explore possible problems and even re-start the application with proper state.
We should create JPA models to store in a DB (in-memory) the scrapping and update process of our models; the access-layer would use the repository pattern (with Quarkus Panache). The entities to consider at the moment should be:
We should keep the models simple and evolve from there as at the moment this will be only an internal representation. This means that the only relations would be between cards and sets through the prints. Evolution of this models for more efficiency (and even use as an output eventually) would happen later (we should open tickets for that).
We should decide as we implement if we want to keep a different ID for those models as our UUID might not be present (this problem is highlighted in #5, as unreleased objects might not have an UUID, or will have it changed).