extract_uncles

[Mschnuff]

work in progress

changes allow to check if uncles exist (currently with text output in terminal). contains some warnings due to the lack of generics. I assume the datatype of an uncle is String. But since I havent actually seen one yet, I did not use generics. Tried to use streams though.

I also want to point out that i am not sure if the code is even logically correct. all i get in the end is an empty list, which is what i expect. But no guarantee.

[kiview]

You can change the PR to draft, then it's clear that it's WIP.

[kiview]

If you don't know of the code is correct, the best way to counter check is is by having a unit test :) In this case you would mock/stub a block that contains uncles and here you would assert the correct behavior.

Also a hint: You changed the method to return a type List public List writeOutTransactions(). TBH, now the code is even complicated for me, in order to quickly assert if it is correct or not. In this case, your method is now performing a side effect (writing into sequence writer) and at the same time having an unrelated return value (List of uncles? I am honestly not sure, also since you left out the generic type of List. I would assume type could be something like a nested collection?)

So idea is good, have a simple experiment, but code needs to become much simpler.

Also note, the data type if Uncles is indeed a String. But don't assume such things, look them up in the source code. This is one of the benefits of Open Source, we can directly look into the implementation and the easiest way to do is is by doing ctrlr + b in IntelliJ, bringing you directly to the interesting code.

So what I did was writing:

client.getEthBlock(blockBigInteger).getBlock().getUncles();

If you now navigate into the getUncles() method, you see the type directly:

public List<String> getUncles() {
            return this.uncles;
}

[Mschnuff]

If you don't know of the code is correct, the best way to counter check is is by having a unit test :) In this case you would mock/stub a block that contains uncles and here you would assert the correct behavior.

Also a hint: You changed the method to return a type List public List writeOutTransactions(). TBH, now the code is even complicated for me, in order to quickly assert if it is correct or not. In this case, your method is now performing a side effect (writing into sequence writer) and at the same time having an unrelated return value (List of uncles? I am honestly not sure, also since you left out the generic type of List. I would assume type could be something like a nested collection?)

So idea is good, have a simple experiment, but code needs to become much simpler.

Also note, the data type if Uncles is indeed a String. But don't assume such things, look them up in the source code. This is one of the benefits of Open Source, we can directly look into the implementation and the easiest way to do is is by doing ctrlr + b in IntelliJ, bringing you directly to the interesting code.

So what I did was writing:

client.getEthBlock(blockBigInteger).getBlock().getUncles();

If you now navigate into the getUncles() method, you see the type directly:

public List<String> getUncles() {
            return this.uncles;
}

So in the end i get

List<List<String>>

right? cus each block can have several uncles, thus a list of string and then off course we extract them from many blocks at once. so that the second list.

[Mschnuff]

well think this should be closed, right?

[kiview]

Closed since there are not uncles as far as we understand. If someone wants to go on digging after uncles, he can use this branch: https://github.com/internet-sicherheit/ethereum-cache-creator/tree/are-there-uncles