Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

type support for properties #470

Merged
merged 74 commits into from
Nov 21, 2023
Merged

Conversation

pnoltes
Copy link
Contributor

@pnoltes pnoltes commented Jan 12, 2023

This PR add some type support to celix_properties_t. Type support for properties are added so that #432 can be solved in type-aware manner.

Looking at the LDAP spec, the filter attribute type should lead to the correct order comparison.
And because in Celix a "service.version" properties is used to identify the runtime version of a service, it should be possible to add a "service.version" property value as celix_version_t type so that celix_version_compareTo can be used to compare "celix.version" attributes.

For now I want to keep this PR draft, for 2 reasons:

  • In this PR, celix properties are no longer a typedef of hash_map, and this is a backwards incompatible update. IMO this PR should only be merged if the next Celix release is going to be a 3.0.0 release
  • Concerning Filter version comparison #432, I think it is better to first solve this differently. Akin what @tira-misu purposes in the issue. Although I think adding some type support for properties is eventually a better solution (especially considering performance), for now a solution that does not require a major version update is preferred.

But comments are welcome :)

Overview changes:

  • Add missing doxygen for celix_properties.h
  • Reimplement celix_properties_t using celix_string_hash_map_t instead of hashmap
  • Add support for long, double, bool and celix_version_t types for property values
  • Add a "short properties" optimization, so that most service properties only need a single malloc.
  • Move and update version cpputest to gtest
  • Move and update properties cpputest to gtest
  • Add C++ Version wrapper for the celix_version_t
  • Replace usage of hashMapIterator on properties and CELIX_PROPERTIES_FOR_EACH to CELIX_PROPERTIES_ITERATE

@pnoltes pnoltes marked this pull request as draft January 12, 2023 10:50
@PengZheng
Copy link
Contributor

Nice! I'll have a detailed look at this.

@codecov-commenter
Copy link

codecov-commenter commented Jan 12, 2023

Codecov Report

Attention: 57 lines in your changes are missing coverage. Please review.

Comparison is base (25463cf) 81.65% compared to head (929ed1e) 83.12%.

❗ Current head 929ed1e differs from pull request most recent head 95460e9. Consider uploading reports for the commit 95460e9 to get more accurate results

Files Patch % Lines
libs/utils/src/properties.c 94.93% 24 Missing ⚠️
libs/framework/src/service_reference.c 0.00% 13 Missing ⚠️
libs/utils/src/celix_hash_map.c 96.77% 7 Missing ⚠️
...ubsub_admin_websocket/src/pubsub_websocket_admin.c 0.00% 4 Missing ⚠️
libs/utils/include/celix/Properties.h 95.78% 4 Missing ⚠️
...e_service_admin_dfi/src/remote_service_admin_dfi.c 50.00% 3 Missing ⚠️
...e_services/topology_manager/src/topology_manager.c 0.00% 1 Missing ⚠️
libs/utils/src/utils.c 83.33% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #470      +/-   ##
==========================================
+ Coverage   81.65%   83.12%   +1.46%     
==========================================
  Files         252      254       +2     
  Lines       32559    32935     +376     
==========================================
+ Hits        26587    27377     +790     
+ Misses       5972     5558     -414     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@pnoltes
Copy link
Contributor Author

pnoltes commented Feb 6, 2023

@pnoltes pnoltes mentioned this pull request Apr 6, 2023
42 tasks
@pnoltes
Copy link
Contributor Author

pnoltes commented Apr 9, 2023

Note because this will be merged when Celix 3.0.0 is prepared also:

  • Update the put functions for celix string/long hash map with a celix_status_t return so that the return value can be used to indicate a CELIX_ENOMEN error. Note that currently the previous stored value is returned.
  • Update the celix properties set functions with a celix_status_t return so that the return value can be used to indicate a CELIX_ENOMEM error
  • Add celix ei functions for celix string/long hash map put functions and celix properties set functions

…t_for_properties

# Conflicts:
#	libs/framework/include/celix/dm/DependencyManager_Impl.h
#	libs/framework/src/celix_launcher.c
#	libs/framework/src/service_reference.c
#	libs/utils/CMakeLists.txt
#	libs/utils/gtest/CMakeLists.txt
#	libs/utils/include/celix/Properties.h
#	libs/utils/include/celix_properties.h
#	libs/utils/include/celix_version.h
#	libs/utils/private/test/version_test.cpp
#	libs/utils/src/properties.c
#	libs/utils/src/version.c
Copy link
Contributor

@PengZheng PengZheng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An interface for testing (in)equality will be very handy.

Copy link
Contributor

@PengZheng PengZheng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about we provide a unified way of serialization (e.g. netstring) so that it can be used for both file storage and EventAdmin?

@pnoltes
Copy link
Contributor Author

pnoltes commented May 31, 2023

How about we provide a unified way of serialization (e.g. netstring) so that it can be used for both file storage and EventAdmin?

I agree and I will also look into this when we start working on Celix 3.0.0. I also think we should (de)serialize with type information.

…t_for_properties

# Conflicts:
#	libs/utils/CMakeLists.txt
#	libs/utils/gtest/CMakeLists.txt
#	libs/utils/gtest/src/HashMapTestSuite.cc
#	libs/utils/include/celix/Exception.h
#	libs/utils/include/celix_properties.h
#	libs/utils/include/celix_utils.h
#	libs/utils/include/celix_version.h
#	libs/utils/private/test/properties_test.cpp
#	libs/utils/src/properties.c
…d on benchmark output

Also add internal header for long/string hash map and properties so that hash map statistics can
be extracted - in the project - for analysing purposes.
…he/celix into feature/type_support_for_properties
Also add some addition celix properties statistics.
libs/utils/include/celix_long_hash_map.h Outdated Show resolved Hide resolved
libs/utils/src/celix_hash_map.c Outdated Show resolved Hide resolved
libs/utils/src/celix_hash_map.c Outdated Show resolved Hide resolved
PengZheng and others added 2 commits November 13, 2023 21:29
Also add/improve some additional error handling in properties.
@pnoltes
Copy link
Contributor Author

pnoltes commented Nov 18, 2023

I agree that "the index of the end iterator is the same as the size of the map".
The current implementation of celix_stringHashMapIterator_next allows iter->index > map->genericMap.size. Is it intended?

Ah i see, no this was not intentionally and I think it is better to keep the max iterator index on map size. Refactor the index increment for this.

@pnoltes
Copy link
Contributor Author

pnoltes commented Nov 18, 2023

@PengZheng I think I reworked all the remarks.

Could you re-review?

@PengZheng
Copy link
Contributor

PengZheng commented Nov 19, 2023

Ah I see, no this was not intentionally and I think it is better to keep the max iterator index on map size. Refactor the index increment for this.

In the original implementation, index has a well-defined meaning: the entry pointed by the iterator is the index-th entry in this iteration. Without this meaning, the newly added test TEST_F(HashMapTestSuite, IterateWithRemoveAtIndex4Test) seems weird:

    celix_autoptr(celix_string_hash_map_t) sMap = createStringHashMap(6);
    auto iter1 = celix_stringHashMap_begin(sMap);
    while (!celix_stringHashMapIterator_isEnd(&iter1)) {
        if (iter1.index == 4) {
            // note only removing entries where the iter key is even
            celix_stringHashMapIterator_remove(&iter1);
        } else {
            celix_stringHashMapIterator_next(&iter1);
        }
    }
    EXPECT_EQ(4, celix_stringHashMap_size(sMap)); 

4 rather than 5 entries remain. The original implementation and well-defined meaning seems better. Sorry for misguiding you.

index is arguably an external concept, since we don't rely on it to decide whether the current iteration ends:

bool celix_stringHashMapIterator_isEnd(const celix_string_hash_map_iterator_t* iter) {
    return iter->_internal[1] == NULL; //check if entry is NULL
}

bool celix_longHashMapIterator_isEnd(const celix_long_hash_map_iterator_t* iter) {
    return iter->_internal[1] == NULL; //check if entry is NULL
}

Therefore, it is also reasonable to remove index from the interface and implementation.
WDYT?

Copy link
Contributor

@PengZheng PengZheng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only major issue left is the iterator index as mentioned above.
I apologize for the misguidance caused by misunderstanding.

Otherwise, this PR can be merged except for 2 minor issues:
#470 (review)

@pnoltes
Copy link
Contributor Author

pnoltes commented Nov 20, 2023

Therefore, it is also reasonable to remove index from the interface and implementation. WDYT?

I agree. The index field is too confusion and it is trivial to add a counter/index on your own, so I removed the index field.

Copy link
Contributor

@PengZheng PengZheng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work. Now we have a more robutst, more efficient, and well-documented celix_properties_t.

LGTM

@pnoltes pnoltes merged commit e9642b9 into master Nov 21, 2023
28 checks passed
@pnoltes pnoltes deleted the feature/type_support_for_properties branch November 21, 2023 07:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants