You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a user I want to have the most relevant matches by my demand
Tech description:
The initial idea was to:
-- always polls chain by schedule or on each register demand for potential match to execute swapNoParams (= chain record, database record)
-- always pools chain by schedule for Swap event and update database records (= record in database)
However, at this moment, another solution is implemented. If you create potential match on each time when any users registers a new demand it would solve this and outdated data issues:
When you register a new demand there are no yet existing matches and the match table wouldn’t have a new entry. When another user register a new demand, there is a match and it would be added to the table. No duplicates.
When a new demand has been added and search for matches is run, there is no way the PotentialMatches table would have some of existing matches. Any new registered demand would do a whole db search for existing matches and add it to the table. As the ‘no duplicates’ issue has been solved it asserts there would not be any duplicate missed.
Potential sharding would break this schema, but at this moment it is considered as premature optimization.
This task remains open until integration test would be ready and app will pass it.
For more details please check tech documentation on GDrive.
The text was updated successfully, but these errors were encountered:
User story:
As a user I want to have the most relevant matches by my demand
Tech description:
The initial idea was to:
-- always polls chain by schedule or on each register demand for potential match to execute swapNoParams (= chain record, database record)
-- always pools chain by schedule for Swap event and update database records (= record in database)
However, at this moment, another solution is implemented. If you create potential match on each time when any users registers a new demand it would solve this and outdated data issues:
Potential sharding would break this schema, but at this moment it is considered as premature optimization.
This task remains open until integration test would be ready and app will pass it.
For more details please check tech documentation on GDrive.
The text was updated successfully, but these errors were encountered: