v0.44.0 #2832
steven-sheehy
started this conversation in
Releases
v0.44.0
#2832
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Making progress on transitioning our database to CitusDB, this release adds a new
v2
schema with initial support for CitusDB. Automated testing against CitusDB was added to our CI pipeline so that it runs concurrently with thev1
PostgreSQL-based schema. The transaction payer account ID was added to transfer related tables. This will be used as a distribution column for database partitioning across a dimension that is not time-based. This allows the mirror node to scale reads and writes as more transaction payers use the system.The rest of the release is mainly focused around performance improvements. We no longer persist minimal entity information for every entity ID encountered in a transaction. This was a performance drag but also caused problems with our plans to track entity history in an upcoming release. A few of our reference tables were removed in favor of using an application enum instead to map protobuf values to descriptive strings.
On the REST API, retrieval of accounts by public key was optimized to improve its performance. If your application does not require balance information, you can see additional performance gains by setting the new
balance
parameter tofalse
for account API calls. The code was optimized to replaceArray.concat
withArray.push
and to cache entity ID construction. The biggest change is probably the potentially breaking change to thelimit
parameter.Breaking Changes
The maximum number of rows the REST API can return was changed from 500 to 100. Likewise the default number of rows the REST API returns if the
limit
parameter is unspecified was changed from 500 to 25. If a request is sent requesting more than 100 it won't fail. Instead, it will transparently use the smaller of the two values. As a result, this should not be a breaking change unless your application makes assumptions about the exact number of results being returned. We may tweak these values in the future for performance reasons so it's good practice to update your application to handle arbitrary limits and results.Enhancements
Bug Fixes
Dependency Upgrades
@awaitjs
/express from 0.8.0 to 0.9.0 in /hedera-mirror-rest #2743Contributors
We'd like to thank all the contributors who worked on this release!
This discussion was created from the release v0.44.0.
Beta Was this translation helpful? Give feedback.
All reactions