[inmemory] Query does not consider FilterCriteria.getOrdering()

[jlaur]

The query implementation does not consider FilterCriteria.getOrdering().

This is needed in order to correctly support historicState which makes use of this:

https://github.com/openhab/openhab-core/blob/7d1dcd7937ac8810f64691445179b2951d0246bf/bundles/org.openhab.core.persistence/src/main/java/org/openhab/core/persistence/extensions/PersistenceExtensions.java#L113-L126

Expected Behavior

When using historicState from a rule, I would expect the correct item state to be found.

Current Behavior

The first persisted item state is found, i.e. without considering the requested timestamp.

Possible Solution

None yet.

Steps to Reproduce

• Install Energi Data Service (set configuration parameter priceArea to "DK1").
• Install JavaScript Scripting.
• Install InMemory persistence service.
• Create a new Energi Data Service Thing.
• Link channel electricity#spot-price to an item.
• Configure the item with strategy forecast for InMemory.
• Pause/resume the Energi Data Service Thing to trigger persistence using the new configuration.

Create a rule with some trigger and this body:

var hourStart = time.toZDT().plusHours(2).truncatedTo(time.ChronoUnit.HOURS);
console.log("When: " + hourStart);
var price = items.Energi_Data_Service_Spot_Price.history.historicState(hourStart, 'inmemory').quantityState;
console.log("Price InMemory: " + price);
var price = items.Energi_Data_Service_Spot_Price.history.historicState(hourStart, 'jdbc').quantityState;
console.log("Price JDBC: " + price);

Result (example):

2024-01-02 02:14:09.818 [INFO ] [enhab.automation.script.file.test.js] - When: 2024-01-02T04:00+01:00[SYSTEM]
2024-01-02 02:14:09.820 [INFO ] [enhab.automation.script.file.test.js] - Price InMemory: 0.26213750875 kr./kWh
2024-01-02 02:14:09.823 [DEBUG] [istence.jdbc.internal.db.JdbcBaseDAO] - JDBC::query queryString = SELECT time, value FROM Energi_Data_Service_Spot_Price WHERE TIME<='2024-01-02 04:00:00' ORDER BY time DESC LIMIT 0,1
2024-01-02 02:14:09.827 [DEBUG] [jdbc.internal.JdbcPersistenceService] - JDBC: Query for item 'Energi_Data_Service_Spotpris' returned 1 rows in 5 ms
2024-01-02 02:14:09.828 [INFO ] [enhab.automation.script.file.test.js] - Price JDBC: 0.1032499975 kr./kWh

The value returned by InMemory is the first persisted one:

2024-01-02 01:43:09.559 [INFO ] [hab.event.ItemTimeSeriesUpdatedEvent] - Item 'Energi_Data_Service_Spot_Price' updated timeseries [Entry[timestamp=2024-01-01T00:00:00Z, state=0.26213750875 kr./kWh], Entry[timestamp=2024-01-01T01:00:00Z, state=0.24834999125 kr./kWh], Entry[timestamp=2024-01-01T02:00:00Z, state=0.0385625 kr./kWh], Entry[timestamp=2024-01-01T03:00:00Z, state=-2.75E-4 kr./kWh], Entry[timestamp=2024-01-01T04:00:00Z, state=-1.875E-4 kr./kWh], Entry[timestamp=2024-01-01T05:00:00Z, state=-4.625E-4 kr./kWh], Entry[timestamp=2024-01-01T06:00:00Z, state=-1.875E-4 kr./kWh], Entry[timestamp=2024-01-01T07:00:00Z, state=0 kr./kWh], Entry[timestamp=2024-01-01T08:00:00Z, state=7.5E-4 kr./kWh], Entry[timestamp=2024-01-01T09:00:00Z, state=0.385112495 kr./kWh], Entry[timestamp=2024-01-01T10:00:00Z, state=0.4053250125 kr./kWh], Entry[timestamp=2024-01-01T11:00:00Z, state=0.40076248125 kr./kWh], Entry[timestamp=2024-01-01T12:00:00Z, state=0.41258750875 kr./kWh], Entry[timestamp=2024-01-01T13:00:00Z, state=0.4307500075 kr./kWh], Entry[timestamp=2024-01-01T14:00:00Z, state=0.47146251625 kr./kWh], Entry[timestamp=2024-01-01T15:00:00Z, state=0.554000015 kr./kWh], Entry[timestamp=2024-01-01T16:00:00Z, state=0.605424995 kr./kWh], Entry[timestamp=2024-01-01T17:00:00Z, state=0.57514999375 kr./kWh], Entry[timestamp=2024-01-01T18:00:00Z, state=0.57076248125 kr./kWh], Entry[timestamp=2024-01-01T19:00:00Z, state=0.55866249125 kr./kWh], Entry[timestamp=2024-01-01T20:00:00Z, state=0.51161251125 kr./kWh], Entry[timestamp=2024-01-01T21:00:00Z, state=0.44388748125 kr./kWh], Entry[timestamp=2024-01-01T22:00:00Z, state=0.3311750025 kr./kWh], Entry[timestamp=2024-01-01T23:00:00Z, state=0.28504999125 kr./kWh], Entry[timestamp=2024-01-02T00:00:00Z, state=0.18701250125 kr./kWh], Entry[timestamp=2024-01-02T01:00:00Z, state=0.28915000875 kr./kWh], Entry[timestamp=2024-01-02T02:00:00Z, state=0.171362495 kr./kWh], Entry[timestamp=2024-01-02T03:00:00Z, state=0.1032499975 kr./kWh], Entry[timestamp=2024-01-02T04:00:00Z, state=0.12840000125 kr./kWh], Entry[timestamp=2024-01-02T05:00:00Z, state=0.4438249975 kr./kWh], Entry[timestamp=2024-01-02T06:00:00Z, state=0.54138748125 kr./kWh], Entry[timestamp=2024-01-02T07:00:00Z, state=0.61192501125 kr./kWh], Entry[timestamp=2024-01-02T08:00:00Z, state=0.60316249875 kr./kWh], Entry[timestamp=2024-01-02T09:00:00Z, state=0.64277496375 kr./kWh], Entry[timestamp=2024-01-02T10:00:00Z, state=0.6852625275 kr./kWh], Entry[timestamp=2024-01-02T11:00:00Z, state=0.72831253 kr./kWh], Entry[timestamp=2024-01-02T12:00:00Z, state=0.7349250025 kr./kWh], Entry[timestamp=2024-01-02T13:00:00Z, state=0.738375015 kr./kWh], Entry[timestamp=2024-01-02T14:00:00Z, state=0.74508750875 kr./kWh], Entry[timestamp=2024-01-02T15:00:00Z, state=0.7590625 kr./kWh], Entry[timestamp=2024-01-02T16:00:00Z, state=0.75402496375 kr./kWh], Entry[timestamp=2024-01-02T17:00:00Z, state=0.69839996375 kr./kWh], Entry[timestamp=2024-01-02T18:00:00Z, state=0.58872501375 kr./kWh], Entry[timestamp=2024-01-02T19:00:00Z, state=0.53216251375 kr./kWh], Entry[timestamp=2024-01-02T20:00:00Z, state=0.436937485 kr./kWh], Entry[timestamp=2024-01-02T21:00:00Z, state=0.37272499125 kr./kWh], Entry[timestamp=2024-01-02T22:00:00Z, state=0.2032250025 kr./kWh]]

Context

I was going to prepare an example for setting up InMemory persistence and getting prices at specific points in time from a rule. This would then obsolete the raw JSON channel electricity#hourly-prices: https://www.openhab.org/addons/bindings/energidataservice/#channel-group-electricity

Your Environment

• Version used: 4.2.0-SNAPSHOT - Build 3816

[jlaur]

@J-N-K - not sure if you automatically see issues, so pinging you just in case. I was (finally) playing with the inmemory persistence yesterday and quite quickly ran into this issue. I didn't see any quick way to fix this with the current design, so for now decided just to document my observations.