-
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
Feature/es voting stat plugin #1983
base: develop
Are you sure you want to change the base?
Feature/es voting stat plugin #1983
Conversation
added also switch cases in later commis replaced case label with static constexpr method from abstract object
c214135
to
47861c9
Compare
Note that you can create "draft" pull requests. |
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.
How does the new plugin affect replay time
- when turned off?
- when turned on (without ES-objects plugin)?
libraries/chain/include/graphene/chain/voting_statistics_object.hpp
Outdated
Show resolved
Hide resolved
libraries/chain/include/graphene/chain/voteable_statistics_object.hpp
Outdated
Show resolved
Hide resolved
/** | ||
* Emitted after the beginning of the maintenance interval | ||
*/ | ||
fc::signal<void(uint32_t)> on_maintenance_begin; |
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.
Nice, this resolves #211.
/** | ||
* Emitted after the calculation of the voting_stake (occurs in the maintenance interval) | ||
*/ | ||
fc::signal<void(const account_object&, const account_object&, const uint64_t)> on_voting_stake_calculated; |
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.
Hm, unsure if we want to add such a specific signal. @abitmore @jmjatlanta?
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.
At a glance I don't like it. Is there any way to avoid this?
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.
I need all the data to properly feed the plugin, so AFAIK there is no way to avoid this. Everything is performed inside the vote_tally_helper
and nothing is given outside.
What exactly do you don't like? Is the signal signature too specific?
To make it more generic I could switch the emission signature to emit an object with the data. This would make it extensible. It would be up to the signal receiver to use the data or not.
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.
If I understood correctly, void(const account_object&, const account_object&, const uint64_t)
means we need to emit the signal once per account, which IMHO is too many. I think it's easier if we add the voting_stake
data directly into account_statistics_object
as a member variable, although this would need a bit more memory.
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 you are right. The signal is emitted once per account.
Inserting data in account_statistics_object
would mean double tracking of the data. Also it would then insert always (or make a check whether the plugin is active, but this seems weird IMHO). But the plugin kinda looses its purpose then.
What would be if I gathered the data first and then emit the signal with all the data? This would call the signal only once and wouldn't require more memory to be used. Though still would require a check whether the plugin is active or not.
libraries/plugins/voting_stat/include/graphene/voting_stat/voting_stat_plugin.hpp
Outdated
Show resolved
Hide resolved
tests/CMakeLists.txt
Outdated
@@ -52,4 +52,8 @@ target_link_libraries( es_test | |||
graphene_es_objects graphene_egenesis_none graphene_api_helper_indexes | |||
fc ${PLATFORM_SPECIFIC_LIBS} ) | |||
|
|||
file( GLOB VOTING_STAT_SOURCES "voting_stat/*.cpp" ) | |||
add_executable( voting_stat_test ${COMMON_SOURCES} ${VOTING_STAT_SOURCES} ) |
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.
Please move general tests into normal test suite and ES-specific tests into ES test suite. A separate executable will most likely not be run by developers.
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.
Okay will do that.
0f0ad85
to
b53b254
Compare
_maint_block = block_num; | ||
_create_voteable = true; | ||
} | ||
++_maint_counter; |
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.
This will not work properly. If there's a fork around the maintenance interval, the counter may be incremented multiple times for a single maintenance interval, and not consistently across all nodes.
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.
Hm now this is a bit of a problem. But if I would just remove that (ignore the fact that we then can't control the number of objects we track) wouldn't there be the same problem? That different objects will be pushed to es from different nodes?
Is there some form of signal which could be applied on_fork
? That would decrement the counter?
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.
No, but you can detect the switch to a fork in applied_block
- block numbers should increase strictly monotonically, i. e. if the new block number is the same or lower than the previous you know that the chain is switching to a fork.
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.
Ah okay. Understood. Will rebuild that.
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.
I have still some problems with that. E.g. on_maintenance_begin
is called and the plugin routine is performed. Now a fork appears, which leads to another maintenance interval.
AFAIU the plugin routine should now be applied to the fork maintenance.
So when something like that happens I need to revert the changes from the previous interval and apply the plugin routine to the fork interval. Please correct me if I am wrong.
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.
Actually knowing that the chain is switching to a fork is not enough, because in extreme cases a fork can span more than one maintenance interval.
A catch-all solution would be to store the counter in a database field instead of using an instance variable. Database entries are rolled back automatically when switching to a different fork.
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.
Okay I see. I'll try to figure that out. But in such cases there should also be problems with es_objects
plugin I think. For example I have added a forbid_delete_flag
which forbids the es_objects
delete operation for vote*_objects
(so it's possible to delete them in the plugin but still store them in es). Meaning a fork appears, rerolls the objects, which should normally delete them (probably). But this doesn't happen.
But in general I think I understood your solution. I will create a db object
which keeps track of the counter.
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.
Meaning a fork appears, rerolls the objects, which should normally delete them (probably). But this doesn't happen.
Correct. IIRC we decided that it doesn't matter because objects will eventually be overwritten by new objects with the same ID.
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.
Ah indeed, you are right. Okay then I think I got no further question for now. Thanks for the help.
5ca7486
to
c4a679d
Compare
c4a679d
to
f47e5ba
Compare
Sry for the last PR (#1971), here is now the clean one.
Like said, still not fully mature.