journal - make timestamp generic about engula HOT 7 CLOSED

@Xuanwo we introduce Timestamp to avoid this conversion.

Suppose we force Timestamp as u64 and let users convert their own types to a u64. It sounds reasonable for several cases. But a DateTime may fail to convert to u64 with UNIX epoch conversion if it exceeds. Also, a hybrid logic clock may hard to be convert into u64. That's why we introduce Timestamp abstraction - release users from considering all of this stuff.

from engula.

I made a try in this branch but believe there must be some best practices I miss - code should never be written as this XD.

Even I make Timestamp a simple Ord bounded trait it brings <Timestamp: Ord + Display + Send + Clone + Copy> everywhere. And I have to make two hacks.

1. Introduce 'static + to workaround lifetime gap in async context (which IMO is a unreasonable restriction for this concept).
2. Change .unwarp_or(0) to .unwrap due to Ord itself doesn't provide a reasonable "default" in "last_ts" context. We may introduce a new trait but I don't have a good background on it.

from engula.

Well I reduce the repetition a bit by factoring out:

pub trait Timestamp: Ord + Display + Send + Copy {}
impl<T> Timestamp for T where T: Ord + Display + Send + Copy {}

but the two questions above remain.

from engula.

I guess unwrap_or(0) means unwrap_or_default and add a trait bound Default to overcome the first question. Here is the draft pull request #103 .

However, I don't still work well with lifetime, and am unsure whether Timestamp is so basic and essential that we almost affect every abstraction in journal - is it worth?

from engula.

Sorry for jumping into this discussion without more research.

As we will store the journal remotely, we need to consider how to ser/de the Timestamp. Compared to using a trait, maybe we can use a struct here, and let users decide how to convert their Timestamp into ours?

from engula.

As we will store the journal remotely, we need to consider how to ser/de the Timestamp. Compared to using a trait, maybe we can use a struct here, and let users decide how to convert their Timestamp into ours?

Can you elaborate a little bit? I don't see how a struct solves the problem here.

from engula.

Well, I got it. Thanks for explaining to me!

from engula.