-
Notifications
You must be signed in to change notification settings - Fork 499
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
services/horizon/internal/db2/history: Implement loaders for assets, claimable balances, and liquidity pools #5019
Conversation
services/horizon/internal/db2/history/claimable_balance_loader.go
Outdated
Show resolved
Hide resolved
|
||
// GetNow returns the internal history id for the given liquidity pool. | ||
// GetNow should only be called on values which were registered by | ||
// GetFuture() calls. Also, Exec() must be called before any GetNow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a functional pattern that could help drive the required timing/coordination between methods more from compile time, like GetNow
as an instance returned from Exec
:
type GetNow(id string) int64
func (a *LiquidityPoolLoader) Exec(ctx context.Context, session db.SessionInterface) (GetNow, error) {...}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we will only invoke GetNow()
indirectly when the futures are are serialized into SQL statements. I could make GetNow()
a non-exported method so that the only way it is called is through the futures. Do you think that would be better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, that sounds good approach, might prevent incorrect usage later, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great work, good dialog about code duplication in the loader, refactor ideas, room for iterations on that later.
PR Checklist
PR Structure
otherwise).
services/friendbot
, orall
ordoc
if the changes are broad or impact manypackages.
Thoroughness
.md
files, etc... affected by this change). Take a look in the
docs
folder for a given service,like this one.
Release planning
needed with deprecations, added features, breaking changes, and DB schema changes.
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
What
Implement loaders for assets, claimable balances, and liquidity pools.
Why
See #5015 for motivation.
Known limitations
[N/A]