-
Notifications
You must be signed in to change notification settings - Fork 647
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
The database API is huge, messy and inconsistent #95
Labels
Milestone
Comments
I like the idea of separate this while keeping access from api id 0. anyone have ideas we can discuss on how to implement ? |
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From @theoreticalbts on September 24, 2015 17:47
Problems in the database API:
Accounts have different functions (1)-(2) to get accounts.
Assets have a single function (3) which accepts symbols or stringified ID's.
Accounts have a function (4) to get a single account by name, everything else uses vectors.
get_full_accounts (5) gets the account object and associated objects, nothing else has anything similar. It would
be useful to have other queries which fetch an object and all related objects, e.g. given a BitAsset,
fetch the asset object, BitAsset data structure, and the asset object for the base asset.
Methods (6), (7), and (8) do the same thing but have different names.
Methods (9), (10), and (11) have no way to request later pages. Furthermore, on reading the code,
the limits are not enforced by some of these methods.
Maximum number of things to query should be consistent and enforced. We
may want to provide local wrappers for methods which return iterators, possibly
with latency hiding (e.g. instead of having it block for the whole round trip
when you reach the end of the iterator, instead have it send off the request
for the next page when the iterator reaches the halfway point of the current
page).
The database API needs to be refactored, broken apart into multiple simpler API's. The sections in
database_api.hpp
could conceivably be separately implemented (although we need some kind of union API to make them all accessible to clients under API ID 0).Copied from original issue: cryptonomex/graphene#338
The text was updated successfully, but these errors were encountered: