Persistence: store with timestamp [message #1738185] |
Sun, 17 July 2016 18:46 |
|
If I understand the current persistence interface correctly, there exist a method to store the state of an item.
This method is called with the item as the only argument.
The only timestamp that could be used to stored the state is the current time.
So, shouldn't we add add a timestamp argument there?
Should we add a timestamp to every event -- the timestamp the event has been generated? Is it a good idea or a bad one?
|
|
|
|
|
|
|
Re: Persistence: store with timestamp [message #1738263 is a reply to message #1738257] |
Mon, 18 July 2016 14:06 |
|
Kai Kreuzer wrote on Mon, 18 July 2016 13:49as it will fully break most existing code, which currently relies on the fact that the order of receiving IS the chronological order.
Could you please explain me why adding the creation timestamp to an event will break the chronological order?
Kai Kreuzer wrote on Mon, 18 July 2016 13:53For the persistence service (such as in https://github.com/eclipse/smarthome/pull/1872), I am fine with introducing a new method with a timestamp as this will only store data in the database and have no further direct impact on any other clients - and it is an option that not all persistence services have to support (as Chris introduces a new dedicated interface).
I need to have a look at to Chris PR, but reading the description I assume he wants to add already collected historic data to the persistence service.
That is not my intention.
If I ran two different persistence service (that could be up and down) and I want to merge the persistent data, the same data added could has been added to the two persistence services with different timestamps.
If a state should be persist in separate persistence services we can (IMHO) rely on the fact that the most persistence service will persist the data with a timestamp.
I don't see any reason, why this timestamp should be generated by every persistence service on its own. It would be nice if the framework could call the store with the same timestamp for all persistence services.
|
|
|
|
Re: Persistence: store with timestamp [message #1738267 is a reply to message #1738266] |
Mon, 18 July 2016 14:18 |
|
Kai Kreuzer wrote on Mon, 18 July 2016 14:11Quote:Could you please explain me why adding the creation timestamp to an event will break the chronological order?
Simply because event1(today), event2(yesterday) means that they are not in chronological order anymore?
1. Adding information will not change a order. If this is wrong, we should never add a member to a class
2. If the order has been "1. event1" and "2. event2" and event2 is older then event1, then the order has been already non-chronological.
I assume you interpret (as Chris before) I would like to mix the PR of Chris and a timestamp information to store.
But this is not that I have written. Have I?
I never talked about a relationship between Chris PR and my suggestion.
|
|
|
Re: Persistence: store with timestamp [message #1738306 is a reply to message #1738267] |
Mon, 18 July 2016 20:46 |
|
Kai Kreuzer wrote on Mon, 18 July 2016 14:11Not so the logging persistence service, the rrd4j persistence service and possibly others. That's why I think the additional interface makes sense (and we already have a distinction between queryable and non-queryable services, so this imho fits in here).
I am not against the additional interface.
I am fine with that.
My intention has been that I can store to all PersistenceSerivce implementations using the same timestamp e.g. iterate over all persistence service and store the item on change. Currently this results in different timestamps on every storage.
It is not about filling "old" values in the database, still the "current" one.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05238 seconds