M3 Bug I believe - persistence groups not working

Add-ons Persistence Services
1

Persistence groups aren’t working on a new install of 2.4 M3. If I specify the item name directly into the .persist file it works but otherwise it silently ignores it and gives no messages or signs as to why. wasted pretty much the entire day with this one :frowning:

This is my .persist file. all direct items work. I’m using mysql persistence:

Strategies {
everyHour : “0 0 * * * ?”
everyDay : “0 0 0 * * ?”
default = everyChange, restoreOnStartup
}

Items {
persistChanges* : strategy = everyChange
persistAndRestore* : strategy = everyChange, restoreOnStartup
wake_MasterTimeMins :
wake_Master :
wake_AutoSet :
}

2

make sure your items are not groups in the group

I’m running on M3 and everything works as it should

3

they are not in sub groups -they are there directly. I can tell you that it never even creates the item table for the items / never logs that it needs to watch them. I had m3 via upgrades previously / persistance working in the past .i ‘think’ it was working in m3 still - maybe its just a bug with new items? who really knows as it was a bit of a mess from moving and the whole structure needing to change … I did notice that the persist file gets loaded after the items files if that matters

4

These are not defined. Define the persistence for these items or remove them and it should work

5

Doesnt it use the default persistence, when items isn´t defined seperatly? If not, why is there a default persistence then?

PS. I havn´t tried myself. I always define the persistence for each items…

1 Like
6

I don’t know

Me neither

7

Thank you Kim - just as the docs say in this default file - no strategy defined uses the default from above. Also- as I originally said - the items I have defined directly in this file are working it is only when I try to rely on membership in the persistAndRestore group that nothing works. Also - I am not using nested groups. Items were direct members of the previously mentioned group yet did not get picked up at all. I had the initial items table get created but it was empty.

This is a fresh install that I can confirm acted this way from both docker install and standalone install.

I had an previous install running with the same exact configs that was working at some point. I’ll pull up a backup of those databases and see if / when they stopped archiving.

I have also noticed errors in the past that creep up only on new installs - pre-existing stuff isn’t impacted. These are the rough errors as it can be especially tough for newbies that don’t know the system yet.

8

FYI to any interested parties - I found the problem with my setup. Previously one did not need to have the Group Item explicitly defined within each items file. Seems on newer versions you must define the group item in each items file ahead of the items you want to be persisted. I didn’t realize we could manually define a group more than once across items files. will this have adverse affects?

9

No, that’s not allowed. A Group Item is still an Item and must be unique (i.e. you must not define it twice)

In fact, all my Group Items are defined in a group.items file. Works flawless.

10

Well, “not allowed” … maybe more “not sensible”. The Items files are loaded individually; when a duplicate name is encountered, it’s assumed to be an edit, a replacement for something previously defined. So the “new” definition is accepted as an update.

But defining a Group once, ‘before’ or ‘after’ any of its member Items, should definitely be the way to go.

11

I would say that then if this is not the preferred/allowed behavior then we 100% have a bug as the system requires the group item to be defined within the same items file for group based persistence strategies to work. A single groups.items file would not support that as non of the desired items would be persisted in my tests.

I posted a a bug in github

12

I would suspect that at least in part you are fighting against persistence service non-dynamic nature. It’s a legacy 1.x service, and is not at all clever about in-flight updates. I wouldn’t expect it to take account of Group membership changes until after a restart.