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
{{ message }}
This repository has been archived by the owner on Jun 11, 2024. It is now read-only.
I expect to any custom transaction to be able to store its asset data without creating a migrations.
As a result we can get rid of full_blocks_list view (which is expensive) and its dependant tables:
delegates
votes
signatures
multisignatures
dapps
intransfer
outtransfer
transfer
Actual behavior
Currently, if I want to introduce a new transaction type with assets I have to write a migration to add new table.
By introducing a json field in trs table all related asset can be saved there and different transactions can have different asset structures.
Which version(s) does this affect? (Environment, OS, etc...)
1.5
The text was updated successfully, but these errors were encountered:
That's the improvement we've already planned to do for a long time and which was initially intended to do as part of Lisk Core v1.6.
We will implement this refactor sooner - in Lisk Core v1.5, as the removal of full_blocks_list and doing SQL queries on trs.asset column as JSON directly, will significantly improve the API performance of transactions related endpoints which dropped significantly in Lisk Core 1.5 - #2817.
Expected behavior
I expect to any custom transaction to be able to store its asset data without creating a migrations.
As a result we can get rid of
full_blocks_list
view (which is expensive) and its dependant tables:Actual behavior
Currently, if I want to introduce a new transaction type with assets I have to write a migration to add new table.
By introducing a json field in trs table all related asset can be saved there and different transactions can have different asset structures.
Which version(s) does this affect? (Environment, OS, etc...)
1.5
The text was updated successfully, but these errors were encountered: