-
Notifications
You must be signed in to change notification settings - Fork 184
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
DNM: Revisiting ownership of key and value types #429
DNM: Revisiting ownership of key and value types #429
Conversation
629458e
to
d3a50e7
Compare
3469cf7
to
d19b934
Compare
The most recent commit adds support for But also exciting, @antiguru, are the |
The most recent commit relaxes |
d9ec6db
to
5d8d2c9
Compare
The most recent commit looks large, but it's almost all whitespace due to changing a tab indent level. They introduce functions |
829a09e
to
787cc7a
Compare
@@ -97,7 +98,8 @@ mod val_batch { | |||
#[derive(Abomonation, Debug)] | |||
pub struct RhhValStorage<L: Layout> | |||
where | |||
<L::Target as Update>::Key: Default + HashOrdered | |||
<L::Target as Update>::Key: HashOrdered, | |||
<L::Target as Update>::KeyOwned: Default + HashOrdered, |
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 probably shouldn't be a requirement of the structure itself, but rather the implementations that need to push data in (Default
so we can pad locations, and HashOrdered
for actual owned insertions).
787cc7a
to
7018e90
Compare
This PR works to decouple any relationship between the input data types
D
in collections, and the presented key and value typesK
andV
surfaced by arrangements. There are otherwise a tight coupling of the two, often thatD = (K, V)
, and certainly bothK
andV
must be sized and ownable and all that. However, we would like to break that, to allow e.g. data of the form(Vec<u8>, String)
and key and values respectively&[u8]
and&str
, which are less directly related.We break these links whenever possible, ensuring that the
Arrange
trait expresses opinions only about the data types in input collections, and not at all with respect to the output types of formed traces (except that the timestamps must be comparable). TheJoin
andReduce
trait implementations are now backed by methodsjoin_trace
andreduce_trace
that are each driven by trace typesT1
andT2
, whose requirements are not to input types, but just that some may need to implementToOwned
in order to be captured and maintained for some duration. Elsewhere, we are forced to decorate previously naive types, traits, and methods with caveats likeK: Sized
orK: ToOwned<Owned = K>
or similar implicit assumptions that are now made explicit.