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

Allow placeholders in Cloud SQL config #495

Merged
merged 2 commits into from
Jun 8, 2021
Merged

Allow placeholders in Cloud SQL config #495

merged 2 commits into from
Jun 8, 2021

Conversation

meltsufin
Copy link
Member

Secret Manager placehoders are still skipped as before.

Fixes: #491.

Secret Manager placehoders are still skipped as before.

Fixes: #491.
// Bind properties without resolving placeholders
Binder binder = new Binder(ConfigurationPropertySources.get(environment), null, null, null, null);
// Bind properties without resolving Secret Manager placeholders
Binder binder = new Binder(ConfigurationPropertySources.get(environment), new PlaceholdersResolver() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Want to refactor this into a nested class? It's not so trivial, plus there are additional parameters after the anonymous class...

@sonarcloud
Copy link

sonarcloud bot commented Jun 8, 2021

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

100.0% 100.0% Coverage
0.0% 0.0% Duplication

@meltsufin meltsufin merged commit 157e38c into main Jun 8, 2021
@meltsufin meltsufin deleted the sql-placeholders branch June 8, 2021 19:11
kateryna216 added a commit to kateryna216/spring-cloud-gcp that referenced this pull request Oct 20, 2022
Secret Manager placehoders are still skipped as before.

Fixes: GoogleCloudPlatform#491.
prash-mi pushed a commit that referenced this pull request Jun 20, 2023
This PR adds three additional types of parameter binding:
1) primitive arrays. These were straightforward to match, knowing the incoming object type, and are implemented with existing `ClientLibraryTypeBinderImpl`.
2) wrapper type arrays or primitive arrays where type conversion is needed. These need to be converted from an array to a list to use the list-accepting overloads of client library value binder. I've implemented a helper class `ArrayToIterableBinder` to avoid duplicating list creation boilerplate.
3) Iterable/Collection. This was harder, since the client library has typed binding methods, but parameterized types aren't real ("reified") in Java. This is, however, possible with R2DBC SPI 0.9 `Parameter.in()` binding. It's implemented with one binder for all `Iterable` needs -- `IterableBinder`, which uses some hardcoded type maps in `SpannerType`. I've updated `ClientLibraryTypeBinder` to accept `SpannerType` hints, but for now only the `IterableBinder` uses these values. We may have use for the additional type hinting in the future, though, so we might as well give the binders all useful information up front.

 (3) is not necessary to bind collections with Spring Data, because all collections get converted to arrays internally, so by the time the value gets to the driver, it's already an easily digestible array.  `SpannerArrayColumns` and `SpannerR2dbcDialect` changes are needed to trigger this logic in Spring Data.

I've simplified the front-end to send and retrieve a whole Book object, because adding another field with another button would be too complicated for users.

Fixes #481.
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.

No environment placeholder in configuration properties
3 participants