Skip to content

Align BatchSpec with StatementSpec - #37502

Closed
quaff wants to merge 1 commit into
spring-projects:mainfrom
quaff:patch-171
Closed

quaff wants to merge 1 commit into
spring-projects:mainfrom
quaff:patch-171

Conversation

@quaff

@quaff quaff commented Oct 16, 2026

Copy link
Copy Markdown
Contributor

No description provided.

Signed-off-by: Yanming Zhou <zhouyanming@gmail.com>
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Oct 16, 2026
@quaff

quaff commented Oct 16, 2026

Copy link
Copy Markdown
Contributor Author

@sbrannen I think you missed this method in commit 833ab4d, feel free to close if it's intentional.

@sbrannen sbrannen self-assigned this Oct 16, 2026
@sbrannen sbrannen added in: core Issues in core modules (aop, beans, core, context, expression) in: data Issues in data modules (jdbc, orm, oxm, tx) and removed in: core Issues in core modules (aop, beans, core, context, expression) labels Oct 16, 2026
@sbrannen

Copy link
Copy Markdown
Member

Hi @quaff,

Thanks for the PR and for keeping an eye on the JdbcClient batch support.

Omitting a varargs entry(Object...) method was intentional when we redesigned BatchSpec in #37341.

The main concern is that BatchSpec already has entries(Object...), so we would end up with two varargs overloads that accept the same argument types but have opposite semantics, distinguished only by the method name:

  • entry(a, b): one entry with two positional parameters
  • entries(a, b): two entries, each a named parameter object

Mixing them up would still compile and fail only at runtime (or silently bind the wrong values) — the very class of problem that motivated replacing add() in the first place. Similarly, entry(Object...) would accept a single DTO or record (for example, entry(user)) and bind it as one positional parameter, whereas that currently results in a compile error.

Since entry(List.of("Jane", "Smith")) is only marginally more verbose, we don't think the convenience outweighs that risk.

In light of that, I'm closing this PR, but thanks again for the proposal!

@sbrannen sbrannen closed this Oct 17, 2026
@sbrannen sbrannen added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Oct 17, 2026
@quaff

quaff commented Oct 19, 2026

Copy link
Copy Markdown
Contributor Author

Since entry(List.of("Jane", "Smith")) is only marginally more verbose, we don't think the convenience outweighs that risk.

List.of(...) doesn't accept null values, that's reason I spotted this, please reconsider.

@sbrannen

Copy link
Copy Markdown
Member

List.of(...) doesn't accept null values, that's reason I spotted this, please reconsider.

That's a fair point.

List.of(...) was admittedly a poor example on my part since it rejects null elements.

However, null values are already supported:

  • entry(Arrays.asList("Jane", null)), since Arrays.asList(...) permits null elements
  • entry(entry -> entry.param("Jane").param(null)), optionally with an explicit SQL type — for example, entry.param(2, null, Types.VARCHAR)

So, the overload ambiguity with entries(Object...) remains our main concern, and we'd still prefer not to introduce entry(Object...).

We will, however, improve the documentation for entry(List) to point out how to supply null values.

@sbrannen

Copy link
Copy Markdown
Member

We will, however, improve the documentation for entry(List) to point out how to supply null values.

See 405cf56.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

in: data Issues in data modules (jdbc, orm, oxm, tx) status: declined A suggestion or change that we don't feel we should currently apply

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants