Skip to content
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

Serialize ops in account history objects #446

Closed
theoreticalbts opened this issue Sep 20, 2016 · 5 comments
Closed

Serialize ops in account history objects #446

theoreticalbts opened this issue Sep 20, 2016 · 5 comments
Assignees

Comments

@theoreticalbts
Copy link
Contributor

We need to serialize ops to get account history plugin to work with the new DB architecture:

  • There's no way to propagate a custom allocator through static_variant
  • Thus, static_variant is unusable from the database if any member types have fields that require dynamic memory allocation
  • As a consequence, we can no longer store operation in any database object

The "fix" is to serialize history objects.

@theoreticalbts theoreticalbts self-assigned this Sep 20, 2016
@theoreticalbts
Copy link
Contributor Author

A fair amount of refactoring is needed to support this change.

Cleanup of where things are located:

  • Move history objects to account_history_plugin
  • Move impacted.hpp from app to account_history_plugin
  • Update other plugins that reference impacted.hpp to require account_history_plugin at build time

Cleanup of notification API:

  • Some plugins care about deserialized ops
  • Therefore, object passed to pre/post apply hooks should be deserialized
  • account_history_plugin serializes objects
  • Therefore we need a new non-database type for storing unserialized operations. Call this type operation_notification

Since we're breaking the hook API anyway, I'll also modify it to have operation_notification be passed into both pre- and post-apply, instead of the current behavior (which is returning from pre-apply). This should avoid some unnecessary copying. For further savings, since it's no longer a DB object we can store a reference to the operation in the object.

@theoreticalbts
Copy link
Contributor Author

theoreticalbts commented Sep 20, 2016

The operation_object formerly played three different roles, which are now implemented by three different objects:

  • steemit::chain::operation_notification : Used to send a signal to in-process plugin indicating that an operation has occurred. Operation is reference to transient object.
  • steemit::chain::operation_object : Used to store operations in DB. Operation is serialized value.
  • steemit::app::full_operation_object steemit::app::applied_operation : Used to return results in API. Operation is operation value.

@theoreticalbts
Copy link
Contributor Author

There was a size check which didn't record operation history for operations of 128MB or less. This threshold seems unrealistically large, perhaps it was intended for 128KB? Regardless, I removed it.

@theoreticalbts
Copy link
Contributor Author

Renamed full_operation_object to applied_operation to avoid check_reflect.py issues.

@theoreticalbts
Copy link
Contributor Author

Merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant