No,
We are counting the number of transactions we are traversing. We are not even validating the signatures.
This seems like a worse non-solution than max of before - you’ll only likely be able to give a rule-of-thumb estimate (which is either wrong, or ineffectual). I’d caution against an irrational fear to use the db schema.
Apparently too much time was spent discussing the correct solution and how would it would fit with local snapshots. We decided to do a fix which will resolve the issue for now, while we can think this through quietly.
1 Like
You can do something as simple as add a column family (without changing another column family). It would take 5 minutes, you can make it create itself automagically on node start with an existing database. The first time through the consistency check, it might take a few seconds to validate, but it would just work after that.
1 Like
Just for the sake of clarity, I wonder @gal.rogozinski if you wouldn’t mind writing the eventual resolution here, as this was resolved a few weeks ago.
Even better, maybe somebody would like to do a blog post on this experience?
1 Like
@gal.rogozinski, better late than never!
The reason there was never a write up was because I wanted to wait until the real solution was implemented. The real resolution is pretty much the referencedMilestone mentioned by @anon45419615:
I propose changing the IRI database scheme:
- add a
referencedMilestonefield (= max(milestone referened via branch, milestone referenced via trunk))
In the mean while we have a solution that counts the number of transactions in belowMaxDepth and then returns once we exceeded 20,000.
We need to make this a priority again and see if we want to implement the referencedMilestone solution.