Prototype/example of an adapter that doesn't leverage the internal datastore #58
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a prototype to explore if it's possible to build an adapter that is not leveraging the internal datastore (related to #57)
For this example I modified example3 (still in review #53) to bypass the internal datastore by reimplementing the 5 main methods on the adapter that are interacting with the datastore (
get
/get_all
/get_by_uids
/add
/remove
).I moved the logic of
get
/get_all
andget_by_uids
to each model class instead.it's working but it's significantly slower, especially when doing a sync with a very small diff, I need to investigate further why but it's a good start.
One thing I noticed is that DiffSync is currently expecting
get_all
andget_by_uids
to return a list where it would be useful to accept of generator instead to improve the processing and the memory consumption.I'd love to get some feedback on this experiment and how we could package that into DiffSync if we want to move forward.