properly functioning REQ custom filters implementation #191
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
hi, eric. re: REQ custom filters (like
"#g", "#d", #<any_single_character>, etc) which currently do not function properly inFiltersclass (as itscustomTagQueryfield key is literally the fixed value#customTagQuery):i'd tried several techniques to achieve
#<any_single_character>filter using dynamically defined JSON keys with existingCustomGenericTagQueryListDeserializer(& several attempted variants of it) also with & withoutCustomFiltersListDeserializer(several attempted variants of it as well)- operating on aCustomTagQueryobject- yet unfortunately all have been unsuccessful thus far.in the meanwhile, this PR is a functioning alternate implementation whereby defined JSON Filters keys
customTagQueryfield inFiltershave been changed from typeCustomTagQuerytoMap<String, String>using jackson dynamic object mapping (see links below) functioning as expected for relevant classes:all of which are demonstrated & functioning as expected in
JsonParseTest.per your interest/consideration, a few thoughts as follows:
run this PR by you in the event you might be able to refactor its functionality using
GenericTagQueryas an object rather than myMap<String, String>implementation.if you haven't a solution for the above, and assuming unit/integration tests complete successfully against your nostr relay variant, consider this PR for your eval/comment/approval/etc so that nostr-java (and superconductor) can both minimally support custom REQ filters.
note: now that serialization/deserialization is handled using
Map<String, String>& the jackson@JsonAnyGetter/@JsonAnyGetterannotations, previous custom serializer/deserializer implementations are rendered superfluous and have thus have been removed.lmk if any questions/concerns/omissions/etc
useful/relevant jackson dynamic object mapping links:
https://www.geeksforgeeks.org/mapping-a-dynamic-json-object-field-in-jackson-with-java/
https://www.logicbig.com/tutorials/misc/jackson/jackson-any-setter.html
https://www.baeldung.com/jackson-mapping-dynamic-object#using-jsonanysetter