cppserver/database/create_db.sql.in | 7 2 + 5 - 0 !
1 file changed, 2 insertions(+), 5 deletions(-)

 debian/fix_database_scripts
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

update the database creation script to deal with the debian path

Signed-off-by: Picca Frdric-Emmanuel <picca@synchrotron-soleil.fr>

cppserver/database/configure/CMakeLists.txt | 1 1 + 0 - 0 !
cppserver/database/my.cnf.in | 515 515 + 0 - 0 !
2 files changed, 516 insertions(+)

 debian/my.cnf.in
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

set the right parameters for the mysql configuration file

Signed-off-by: Picca Frdric-Emmanuel <picca@synchrotron-soleil.fr>

doc/CMakeLists.txt | 4 0 + 4 - 0 !
1 file changed, 4 deletions(-)

 doc/html is being excluded in d/copyright.

CMakeLists.txt | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 [patch 1/2] assets/cmakelists.txt: use new package root variable to
 override location

From 5192f5ff7a95cae1ae22f2452eb39fd4ba924794 Mon Sep 17 00:00:00 2001

cppserver/database/configure/CMakeLists.txt | 1 1 + 0 - 0 !
cppserver/database/create_db_tables.sql.in | 14 7 + 7 - 0 !
cppserver/database/test/test.cpp | 27 27 + 0 - 0 !
cppserver/database/update_db_from_5.23_to_5.24.sql.in | 11 11 + 0 - 0 !
4 files changed, 46 insertions(+), 7 deletions(-)

 [patch] fix timestamp columns in mariadb 10.11 and newer
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This problem appears in MariaDb 10.11 since default value of
explicit_defaults_for_timestamp changed from OFF to ON, setting it to
OFF (set global explicit_defaults_for_timestamp=OFF;) make the
create_db_tables.sql.in work properly.

Initial patch by Santiago Ruano Rincn with refinements by Graziano
Scalamera.

Upgrade script and tests by the author.

doc/src/source/conf.py | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 update sphinx config to fix ftbfs
 Fixes the following error:
 ERROR: Invalid value `None` in intersphinx_mapping['http://docs.python.org/'].
 Expected a two-element tuple or list.

lib/cpp/src/client/eventkeepalive.cpp | 18 15 + 3 - 0 !
1 file changed, 15 insertions(+), 3 deletions(-)

 [patch 1/2] eventconsumerkeepalivethread: send actual idl when
 execute ZmqEventSubscriptionChange

When we executed ZmqEventSubscriptionChange we sent as client IDL 0, which means for the server, "Guess my IDL", as it was introduced in 01ffb8f4.

After IDL6 release, due to IDL6 devices subscribing to ...idl5_... events, they were re-subscribed as IDL5 devices.

Now we send the actual maximum IDL, supported by the client as we do at the subscription process

lib/cpp/tests/CMakeLists.txt | 1 1 + 0 - 0 !
lib/cpp/tests/catch2_event_reconnection.cpp | 177 177 + 0 - 0 !
2 files changed, 178 insertions(+)

 [patch 2/2] catch2 tests: add "event re-subscribes with the same idl"
 test

In test we check, that after server restart EventConsumerKeepAliveThread re-subscribe all events to the same maximum supported by client IDL

Test does analysis of debug printouts, due to I have not found any other working solution to check, which IDL was requested

lib/cpp/tests/CMakeLists.txt | 1 1 + 0 - 0 !
lib/cpp/tests/catch2_event_old_client.cpp | 374 374 + 0 - 0 !
2 files changed, 375 insertions(+)

 [patch 1/5] catch2_event_old_client: add test to catch duplicate
 event issue

This test reproduces the issue described in #1521.

lib/cpp/src/server/eventcmds.cpp | 76 75 + 1 - 0 !
1 file changed, 75 insertions(+), 1 deletion(-)

 [patch 2/5] dserver::zmq_event_subscription_changed: map client idl
 versions...

... to event data versions.

We didn't introduce new AttributeValue data structures with IDLv6, so we
shouldn't being sending an event for each client version selected.
Instead, we should be sending a ZMQ event for each type of data
structure, one that each client can use.

lib/cpp/src/server/eventsupplier.cpp | 14 13 + 1 - 0 !
1 file changed, 13 insertions(+), 1 deletion(-)

 [patch 3/5] push_att_conf_events: use event data to determine vers

Do not need to consider the version of the device pushing the event when
deciding if we need to add the idl5_ prefix to the event name.  Instead,
the thing that matters is who the event is aimed at.  This can be
determined from the SuppliedEventData based on which pointer is not
nullptr.

lib/cpp/src/server/eventcmds.cpp | 2 2 + 0 - 0 !
lib/cpp/tests/catch2_event_reconnection.cpp | 2 1 + 1 - 0 !
2 files changed, 3 insertions(+), 1 deletion(-)

 [patch 4/5] catch2_event_reconnection: use log from new mapping
 function

lib/cpp/src/include/tango/server/attribute_templ.h | 5 4 + 1 - 0 !
lib/cpp/tests/CMakeLists.txt | 1 1 + 0 - 0 !
lib/cpp/tests/catch2_attr_conf_event.cpp | 51 51 + 0 - 0 !
3 files changed, 56 insertions(+), 1 deletion(-)

 [patch 5/5] attribute::set_upd_properties: handle no database case
 gracefully

When trying to set the attribute configuration without database, we used
to crash inside Attribute::db_access as the returned pointer from get_database() was not valid.

We now skip the database update similiar to what is done in
DeviceImpl::set_attribute_config.