Hi all,
I'm from the Apache StreamPipes project, an IIoT toolbox where we are
currently working on integrating Apache IoTDB as our time series
storage. Currently we are using Influx, but we want to provide support
for IoTDB as well, maybe even replacing Influx in the end if all goes
well.
Right n
Correct. I’m not disputing that. What I’m asking is that it would
be good to have a configuration that either allows overwrites or rejects
duplicates.My scenario is request log data from a server (the device). As it
may be processing multiple requests at once ther
Hi all,
I just noticed that we have a dependency to a SNAPSHOT ratis versions in our
build.
3.1.0-611b80a-SNAPSHOT
I wasn’t too concerned about this as I saw it was just recently set to that,
but having a deeper look, this was changed from yet another snapshot version of
ratis.
The problem i
Hi all,
I am currently working on the Jakarta migration … initially I thought of this
as an experiment in order to find out what the implications would be.
Turns out my gut-feeling was right that this would not be a simple change. Less
for the complexity of the changes, but what they would bring
Hi Trevor,
By "rejects duplicates", you mean you want to keep the first duplicate
timestamp and its corresponding values?(because the following duplicated
ones will be rejected)
Best regards,
Yuan Tian
On Mon, May 13, 2024 at 6:24 PM Trevor Hart wrote:
>
>
>
>
>
Hello Yuan
Correct, the first timestamp and values should be retained.
I realise this is does not align with the current design. I was just asking
whether there was an existing option to operate to block duplicates.
In a normal RDBMS if you try to insert with a duplicate the insert will f
> 1. Checking before insert if the timestamp already exists and remedy on the
> client before resend
> 2. Moving to Nanosecond and introducing some insignificant time value to keep
> timestamp values unique.
Yes these maybe the best solutions for a specific application.
Analysis for IoTDB:
- Re
Thank you! I will implment some work around for now.
I would appreciate some consideration for this option in the future.
Thanks
Trevor Hart
Ope Limited
w: http://www.ope.nz/
m: +64212728039
On Tue, 14 May 2024 15:17:47 +1200 Xiangdong Huang
wrote ---
> 1. Checking before
