Fix/vub for meta on chain and method overloads #451
Conversation
carpawell
requested review from
cthulhu-rider and
roman-khimov
as code owners
contracts/container/contract.go
Outdated
| @@ -277,7 +277,7 @@ func SubmitObjectPut(metaInformation []byte, sigs [][]interop.Signature) { | |||
| } | |||
| } | |||
| vub := getFromMap(metaMap, "validuntil").(int) | |||
| if vub <= ledger.CurrentIndex() { | |||
| if vub <= contract.Call(storage.Get(ctx, netmapContractKey).(interop.Hash160), "epoch", contract.ReadOnly).(int) { | |||
There was a problem hiding this comment.
I'd still expect blocks here. Epochs are too coarse.
There was a problem hiding this comment.
I know you have problems calculating it on different nodes, but this can be solved in different ways.
There was a problem hiding this comment.
And epochs are not much different here.
There was a problem hiding this comment.
I'd still expect blocks here. Epochs are too coarse.
Well, maybe. Still, we need to sync them somehow.
I know you have problems calculating it on different nodes, but this can be solved in different ways.
Like the last block in the current epoch + const? I don't mind but I have nothing to inspire me here. Epochs are just a little bit more closer to our storage.
And epochs are not much different here.
In the node it is currently creation epoch + const.
There was a problem hiding this comment.
But if it's in blocks then that's the value to use, isn't it? One node sets it, others are either OK or not with it (usually they're OK).
There was a problem hiding this comment.
My suggestion is to drop this patch.
There was a problem hiding this comment.
My suggestion is to drop this patch.
i don't mind but what block to use in the nodes then? i can only think of
neofs-contract/contracts/netmap/contract.go
Line 454 in f5a31fd
There was a problem hiding this comment.
You can use current + something, it is exchanged between nodes, so it's not a problem for other nodes to use the value.
carpawell
force-pushed
the
fix/vub-for-meta-on-chain
branch
from
54ecc4c to
841929d
Compare
|
@roman-khimov, I do not like the second commit, but this is how we can fix it. Now, I know that overloads exist, and I want them all to be overloaded, not like they are partly now. But to be fully honest, |
|
Regarding overloads -- it's ok for me for now. |
|
In general, overloaded |
|
Although you can have proper set of puts and putNamed at the same time. |
carpawell
force-pushed
the
fix/vub-for-meta-on-chain
branch
2 times, most recently
from
baa8491 to
dd6fb9a
Compare
|
After a small talk with @roman-khimov, we are making overloads now and deprecating It is now: I suggest all the clients use the last one, it does not duplicate any logic: if you read name and zone, it is non-empty strings. If you asked to enable meta-not-chain, it is read and not-false. Defaults behave as the first one. I do not want to have |
|
First commit dropped BTW. |
The old (already released) ways are kept. Not it is possible to call "put" as Put (4 args), PutNamed (6 args) and PutMeta (7 args). On the client side, it is acceptable to always call "put" with 7 args and just be sure that the last 3 are meaningful. Signed-off-by: Pavel Karpy <[email protected]>
carpawell
force-pushed
the
fix/vub-for-meta-on-chain
branch
from
dd6fb9a to
de118c4
Compare
It now may have additional arg that enables meta-on-chain support and be named, see nspcc-dev/neofs-contract#451. Closes #2877. Signed-off-by: Pavel Karpy <[email protected]>
It is more natural for on-chain operations. Also, it requires handling sync problems when different blocks are used for the same objects on different nodes: two signatures are always attached with epoch duration difference. Refs nspcc-dev/neofs-contract#451. Signed-off-by: Pavel Karpy <[email protected]>
It is more natural for on-chain operations. Also, it requires handling sync problems when different blocks are used for the same objects on different nodes: two signatures are always attached with epoch duration difference. Refs nspcc-dev/neofs-contract#451. Signed-off-by: Pavel Karpy <[email protected]>
It now may have additional arg that enables meta-on-chain support and be named, see nspcc-dev/neofs-contract#451. Closes #2877. Signed-off-by: Pavel Karpy <[email protected]>
It is more natural for on-chain operations. Also, it requires handling sync problems when different blocks are used for the same objects on different nodes: two signatures are always attached with epoch duration difference. Refs nspcc-dev/neofs-contract#451. Signed-off-by: Pavel Karpy <[email protected]>
It is more natural for on-chain operations. Also, it requires handling sync problems when different blocks are used for the same objects on different nodes: two signatures are always attached with epoch duration difference. Refs nspcc-dev/neofs-contract#451. Signed-off-by: Pavel Karpy <[email protected]>
No description provided.