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

Increase FDB Java version to FDB 7.1 #1636

Closed
alecgrieser opened this issue May 3, 2022 · 0 comments · Fixed by #1641
Closed

Increase FDB Java version to FDB 7.1 #1636

alecgrieser opened this issue May 3, 2022 · 0 comments · Fixed by #1641
Assignees
Milestone

Comments

@alecgrieser
Copy link
Contributor

The FDB 7.1 release has a few new APIs, including getMappedRange, that we will want to be able to expose through the Record Layer. We should increase our dependency version to 7.1, which will also require adding the new methods to our implementations of the Transaction interface.

@alecgrieser alecgrieser added this to the 3.2 milestone May 3, 2022
@alecgrieser alecgrieser self-assigned this May 3, 2022
alecgrieser added a commit to alecgrieser/fdb-record-layer that referenced this issue May 3, 2022
alecgrieser added a commit to alecgrieser/fdb-record-layer that referenced this issue May 4, 2022
This increases the FDB Java dependency to FDB 7.1. This keeps the API version at 630 so that the library can still be used to connect to FDB 6.3 and FDB 7.0 clusters, though it would now require using a 7.1 FDB C client as the primary client with the other clients as external clients.

This will allow for additional features to be built on top of FDB 7.1, though we probably want to also complete FoundationDB#1639 so that we can responsibly guard features reliant on 7.1 in environments where the cluster may still be running older FDB server versions.
alecgrieser added a commit to alecgrieser/fdb-record-layer that referenced this issue May 4, 2022
This increases the FDB Java dependency to FDB 7.1. This keeps the API version at 630 so that the library can still be used to connect to FDB 6.3 and FDB 7.0 clusters, though it would now require using a 7.1 FDB C client as the primary client with the other clients as external clients.

This will allow for additional features to be built on top of FDB 7.1, though we probably want to also complete FoundationDB#1639 so that we can responsibly guard features reliant on 7.1 in environments where the cluster may still be running older FDB server versions.
alecgrieser added a commit to alecgrieser/fdb-record-layer that referenced this issue May 4, 2022
This increases the FDB Java dependency to FDB 7.1. This keeps the API version at 630 so that the library can still be used to connect to FDB 6.3 and FDB 7.0 clusters, though it would now require using a 7.1 FDB C client as the primary client with the other clients as external clients.

This will allow for additional features to be built on top of FDB 7.1, though we probably want to also complete FoundationDB#1639 so that we can responsibly guard features reliant on 7.1 in environments where the cluster may still be running older FDB server versions.
@MMcM MMcM closed this as completed in #1641 May 4, 2022
MMcM pushed a commit that referenced this issue May 4, 2022
* Resolves #1636: Increase FDB Java version to FDB 7.1

This increases the FDB Java dependency to FDB 7.1. This keeps the API version at 630 so that the library can still be used to connect to FDB 6.3 and FDB 7.0 clusters, though it would now require using a 7.1 FDB C client as the primary client with the other clients as external clients.

This will allow for additional features to be built on top of FDB 7.1, though we probably want to also complete #1639 so that we can responsibly guard features reliant on 7.1 in environments where the cluster may still be running older FDB server versions.

* Resolves #1640: Dependency bump for 3.2 release

This updates the proto3 version to 3.20.1 and updates a few other dependencies as well. It leaves the guava version at 30.1-jre instead of updating it to 31.1-jre because that causes spotbugs violations regarding nullability problems. I think those errors are because of a possible change in the way Guava handles nullability annotations, but it seems like something we should fix later.

* fix capitalization in documentation
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 a pull request may close this issue.

1 participant