Skip to content

v2.1.0

Choose a tag to compare

@steve-ssh steve-ssh released this 23 Oct 07:33
2acb39e

------------------------------------------------------------------
Features Added in This Release
------------------------------------------------------------------

  • None

------------------------------------------------------------------
Features Deprecated/Removed in This Release
------------------------------------------------------------------

  • None

------------------------------------------------------------------
Other Notes
------------------------------------------------------------------

  1. In some cases, matching against numeric values will be less performant. This is a consequence of fixing bug # 1, listed below. I did my best to minimize the range and extent of the cases where the performance would drop.

  2. The purpose of this release is to address five bugs discovered in previous versions of JSONQuery.

  3. QA efforts related to the bug fixes resulted in an increase of the number of test cases applied to (and included with) this release. Over 9k new test cases were added.

  4. This build does not attempt to take advantage of the great improvements to JSON operation performance afforded by FMP v.22.

  5. I have not performed any true analysis of the effect of FMP v.22 with respect to JSONQuery performance. Cursory experimentation suggests that performance is similar to performance using v.21, or sometimes slightly slower.

------------------------------------------------------------------
Bugs Addressed in This Release
------------------------------------------------------------------

1) Edge cases where some integers supplied as long float values instead of Exp notation were not properly matched.

See test cases with BugFixCode: "DECIMAL_FORMAT"


2) Edge cases where string matching did not enforce diacritic sensitivity.

Generally, JSONQuery performs all matching enforcing diacritic sensitivity, e.g., "Jose" <> "José".

In cases where a child block of JSON contained both the desired diacritic string, as well as the non-diacritically-matching value, the non-matching value would be deemed a match if it matched without diacritic sensitivity.

See test cases with BugFixCode: "DIACRITIC_MATCH"


3) False positive matches could happen when using CONTAINS, CONTAINS_ANY, CONTAINS_CASE_SENSITIVE, ENDS_WITH, ENDS_WITH_ANY, if the target data contained special characters.

JSONQuery uses internal escape sequences in order to properly manage matching against data which may contain special chars such as Line Feed, Carriage Return, Tab, etc.

Such escaping needs to be considered and/or reversed when performing comparison operations.

In the case of CONTAINS and ENDS_WITH matching, escaping needs to be reversed before performing the match operation, but this was not implemented.

The result is that this opened up the opportunity for potential false matches in cases where the supplied match string collided with an internal escape sequence.

See test cases with BugFixCode: "ESCAPE_SEQUENCE"


4) In cases where the FMP file's decimal separator is the comma char, decimal values returned as a single value array, or as a LIST of a single value were incorrect.

This was the result of failing to properly handle the conversion between the dot separator used in JSON, and the proper separator to use for the file.

Note that this bug is limited to very specific circumstances, namely where the ResultPath parameter is set to the path to a single numeric node in the JSON, or a LIST of such a node.

Other numeric operations and comparisons, e.g., SUM, COUNT, NUMERIC_EQUALS, >, <, <=, >=, =, MIN, MAX, AVG were unaffected by this bug, and worked as expected.

See test cases with BugFixCode: "LOCALE_DECIMALS"


5) Applying multiple wildcard sequences in the ResultPath parameter returned incorrect results when applied to an input structure comprised of purely nested arrays.

An example of a "purely nested array" looks something like this:

[
	[
		[
			[ 1, 1, 1 ],
			[ 2, 2, 2 ],
			[ 3, 3, 3 ]
		],
		[
			[ 4, "400.000", 4 ],
			[ 5, "500.000", 5 ],
			[ 6, "600.000", 6 ]
		]
	],
	[
		[
			[ 7, 7, 7 ],
			[ 8, 8, 8 ],
			[ 9, 9, 9 ]
		],
		[
			[ 0, 0, 0 ],
			[ 0, 0, 0 ],
			[ 0, 0, 0 ]
		]
	]
]

Thanks go to Kevin Frank for helping to find this one.

See test cases with BugFixCode: "NESTED_ARRAY"