-
Notifications
You must be signed in to change notification settings - Fork 89
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
Feature/674 improve properties #721
Conversation
# Conflicts: # libs/utils/src/array_list.c
|
(cherry picked from commit 9b4501d)
This PR has been updated so that celix array list types are used, which minimizes the celix properties functions needed for array list handling. After this, I will dive into properties (JSON) serialization. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have reviewed the API parts, and leave some further remarks.
To make this PR easier to follow, I revised all previous remarks to close resolved ones.
Note that there are still remarks that need fix/discussion.
libs/utils/src/properties.c
Outdated
} else if (entry->valueType == CELIX_PROPERTIES_VALUE_TYPE_LONG_ARRAY) { | ||
entry->value = celix_utils_longArrayListToString(entry->typed.arrayValue); | ||
} else if (entry->valueType == CELIX_PROPERTIES_VALUE_TYPE_DOUBLE_ARRAY) { | ||
entry->value = celix_utils_doubleArrayListToString(entry->typed.arrayValue); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WIll a single celix_arrayListToString
be enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And we'll have a single StringToArrayList
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A single StringToArrayList
implies that we should detect the types in the string. This is currently not implemented. I most worry about versions (1.2.3 is a valid version, but also 1.2).
This also triggered me. If we want a properties to (de)serializer to JSON. Do we also want to support / JSON mixed arrays. So something like: [true, 1, 2.3, "string", "1.2.3.qualified"]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we also want to support / JSON mixed arrays. So something like: [true, 1, 2.3, "string", "1.2.3.qualified"] ?
As a dynamically typed language, JS can support heterogeneous arrays.
As a statically typed language, Java supports heterogeneous arrays via "the mother of all" Object.
Here we may need a generic "entry".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am still a a bit worried about JSON serialization and especially empty ([]) arrays, but I will see how we can tackle this a properties JSON serialization pull request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am still a a bit worried about JSON serialization and especially empty ([]) arrays.
Yeah, this is an annoying case.
# Conflicts: # CHANGES.md
…cation. When compiling a filter, it will try to parse arbitrary string as a version. The string length may exceed 64 bytes and thus will trigger unnecessary dynamic memory allocation.
…dle CELIX_ILLEGAL_ARGUMENT of addEntry callback.
…ests for filter. Attributes were ignored when performing equality test between substring filters.
It also replaces celix_utils_stringEquals with cheaper celix_utils_isStringNullOrEmpty.
All issues have been addressed! 🚀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Long awaited typing support of celix_properties_t
finally arrives, together with improved filter. Really exciting improvement.
libs/utils/src/array_list.c
Outdated
@@ -28,6 +28,14 @@ | |||
#include "celix_utils.h" | |||
#include "celix_version.h" | |||
|
|||
#define STRING_VALUE_UNDEFINED_EL_TYPE "CELIX_ARRAY_LIST_ELEMENT_TYPE_UNDEFINED" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "Undefined"/"undefined" will have better readability than "CELIX_ARRAY_LIST_ELEMENT_TYPE_UNDEFINED" as console output.
libs/utils/src/properties.c
Outdated
} else if (entry->valueType == CELIX_PROPERTIES_VALUE_TYPE_LONG_ARRAY) { | ||
entry->value = celix_utils_longArrayListToString(entry->typed.arrayValue); | ||
} else if (entry->valueType == CELIX_PROPERTIES_VALUE_TYPE_DOUBLE_ARRAY) { | ||
entry->value = celix_utils_doubleArrayListToString(entry->typed.arrayValue); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we also want to support / JSON mixed arrays. So something like: [true, 1, 2.3, "string", "1.2.3.qualified"] ?
As a dynamically typed language, JS can support heterogeneous arrays.
As a statically typed language, Java supports heterogeneous arrays via "the mother of all" Object.
Here we may need a generic "entry".
libs/utils/src/properties.c
Outdated
} else if (entry->valueType == CELIX_PROPERTIES_VALUE_TYPE_LONG_ARRAY) { | ||
entry->value = celix_utils_longArrayListToString(entry->typed.arrayValue); | ||
} else if (entry->valueType == CELIX_PROPERTIES_VALUE_TYPE_DOUBLE_ARRAY) { | ||
entry->value = celix_utils_doubleArrayListToString(entry->typed.arrayValue); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am still a a bit worried about JSON serialization and especially empty ([]) arrays.
Yeah, this is an annoying case.
This PR add support for setting and getting string, bool, long, double and a version array list with properties.
Also:
Refactoring the Properties store and load to include properties value type information will be done in a follow up PR.