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

[API-703] v5 SQL: Add default serializers for the new types #459

Merged
merged 5 commits into from
Aug 31, 2021

Conversation

mdumandag
Copy link
Contributor

This PR adds support for the new default types, namely

  • LocalDate -> datetime.date
  • LocalTime -> datetime.time
  • OffsetDateTime -> datetime.datetime
  • LocalDateTime (only deserializing it to datetime.datetime)
  • BigDecimal -> decimal.Decimal

It also fixes the issues on reading/writing big integer objects.

Also, this PR updates the serialization tests with the new types
(+ sum types that are not added before to tests such as aggregators,
projections, ...)

@mdumandag mdumandag added this to the 5.0 milestone Aug 25, 2021
@mdumandag mdumandag self-assigned this Aug 25, 2021
@mdumandag mdumandag force-pushed the new-serializers branch 2 times, most recently from f64a29d to 9b4e588 Compare August 25, 2021 08:46
@codecov-commenter
Copy link

codecov-commenter commented Aug 25, 2021

Codecov Report

Merging #459 (7399e62) into master (d613fc8) will decrease coverage by 0.36%.
The diff coverage is 76.85%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #459      +/-   ##
==========================================
- Coverage   94.47%   94.10%   -0.37%     
==========================================
  Files         345      345              
  Lines       17563    17626      +63     
==========================================
- Hits        16592    16587       -5     
- Misses        971     1039      +68     
Impacted Files Coverage Δ
hazelcast/util.py 79.35% <21.42%> (-4.55%) ⬇️
hazelcast/serialization/serializer.py 97.18% <95.58%> (+1.16%) ⬆️
hazelcast/serialization/serialization_const.py 100.00% <100.00%> (ø)
hazelcast/serialization/service.py 96.93% <100.00%> (+0.19%) ⬆️
...otocol/codec/client_authentication_custom_codec.py 50.00% <0.00%> (-23.81%) ⬇️
hazelcast/reactor.py 79.56% <0.00%> (-7.55%) ⬇️
hazelcast/listener.py 92.30% <0.00%> (-1.93%) ⬇️
hazelcast/connection.py 90.63% <0.00%> (-1.63%) ⬇️
hazelcast/invocation.py 92.72% <0.00%> (-0.77%) ⬇️
hazelcast/proxy/base.py 98.05% <0.00%> (+0.64%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d613fc8...7399e62. Read the comment docs.

@mdumandag mdumandag changed the title v5 SQL: Add default serializers for the new types [API-703] v5 SQL: Add default serializers for the new types Aug 26, 2021
@srknzl srknzl self-requested a review August 27, 2021 06:59
Copy link
Member

@srknzl srknzl left a comment

Choose a reason for hiding this comment

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

Looks good with minors


def int_to_bytes(number):
# number of bytes to represent the number
width = (8 + (number + (number < 0)).bit_length()) // 8
Copy link
Member

Choose a reason for hiding this comment

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

this is hard to understand. I understood the logic but in a quite long time. Maybe add a link to website if you take it from somewhere or else, explain it a bit?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See 9485b4a

Comment on lines +102 to +120
_CONVERSION_TEST_CASES = [
(0, [0]),
(-1, [255]),
(127, [127]),
(-128, [128]),
(999, [3, 231]),
(-123456, [254, 29, 192]),
(2147483647, [127, 255, 255, 255]),
(-2147483648, [128, 0, 0, 0]),
(9223372036854775807, [127, 255, 255, 255, 255, 255, 255, 255]),
(-9223372036854775808, [128, 0, 0, 0, 0, 0, 0, 0]),
# fmt: off
(
23154266667777888899991234566543219999888877776666245132,
[0, 241, 189, 232, 38, 131, 251, 137, 60, 34, 23, 53, 163, 116, 208, 85, 14, 65, 40, 174, 120, 10, 56, 12]
),
(
-23154266667777888899991234566543219999888877776666245132,
[255, 14, 66, 23, 217, 124, 4, 118, 195, 221, 232, 202, 92, 139, 47, 170, 241, 190, 215, 81, 135, 245, 199, 244]
Copy link
Member

Choose a reason for hiding this comment

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

Where did you get these(online or via python interpreter etc.)? Just curious..

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tried different values with Java's BigInteger

@@ -7,6 +7,7 @@ However, we had to edit ``ReferenceObjects`` while generating the file because t
such serializers for the Python client yet. The list of skipped items from ``ReferenceObjects``
are shown below.

* aDate
Copy link
Member

Choose a reason for hiding this comment

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

Maybe we can add a note about this that it was removed due to introducing OffsetDateTime.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is really an internal thing so I don't think it is necessary. I will put a note about the removal of java.util.Date support in the 5.0 release notes

Comment on lines +342 to +344
inp.read_int(),
inp.read_byte(),
inp.read_byte(),
Copy link
Member

@srknzl srknzl Aug 27, 2021

Choose a reason for hiding this comment

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

Are we sure that these will run in this order? (I mean across python versions etc., just to be sure)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If they do that, that would break the public API. So, I don't think it will happen at all.

(-2147483648, [128, 0, 0, 0]),
(9223372036854775807, [127, 255, 255, 255, 255, 255, 255, 255]),
(-9223372036854775808, [128, 0, 0, 0, 0, 0, 0, 0]),
# fmt: off
Copy link
Member

Choose a reason for hiding this comment

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

What does this mean?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is to disable black's autoformatting. It formats this long list one item per line, which does not look good. So, we disable black for this small region

This PR adds support for the new default types, namely

- LocalDate -> datetime.date
- LocalTime -> datetime.time
- OffsetDateTime -> datetime.datetime
- LocalDateTime (only deserializing it to datetime.datetime)
- BigDecimal -> decimal.Decimal

It also fixes the issues on reading/writing big integer objects.

Also, this PR updates the serialization tests with the new types
(+ sum types that are not added before to tests such as aggregators,
projections, ...)
@mdumandag mdumandag merged commit 81f202d into hazelcast:master Aug 31, 2021
@mdumandag mdumandag deleted the new-serializers branch August 31, 2021 10:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants