Skip to content

Conversation

@vbabanin
Copy link
Member

@vbabanin vbabanin self-assigned this Oct 17, 2025
@vbabanin vbabanin requested a review from a team as a code owner October 17, 2025 20:11
@vbabanin vbabanin requested review from nhachicha and removed request for a team October 17, 2025 20:11
@evergreen-ci-prod
Copy link

There is an existing patch(es) for this commit SHA:

Please note that the status that is posted is not in the context of this PR but rather the (latest) existing patch and that may affect some tests that may depend on the particular PR. If your tests do not rely on any PR-specific values (like base or head branch name) then your tests will report the same status. If you would like a patch to run in the context of this PR and abort the other(s), comment 'evergreen retry'.

@vbabanin vbabanin requested review from stIncMale and removed request for nhachicha October 17, 2025 20:11
Comment on lines 189 to 211
@Override
public void addBatch(String mql) throws SQLException {
checkClosed();
throw new SQLFeatureNotSupportedException("TODO-HIBERNATE-35 https://jira.mongodb.org/browse/HIBERNATE-35");
}

@Override
public void clearBatch() throws SQLException {
checkClosed();
throw new SQLFeatureNotSupportedException("TODO-HIBERNATE-35 https://jira.mongodb.org/browse/HIBERNATE-35");
}

@Override
public int[] executeBatch() throws SQLException {
checkClosed();
closeLastOpenResultSet();
throw new SQLFeatureNotSupportedException("TODO-HIBERNATE-35 https://jira.mongodb.org/browse/HIBERNATE-35");
}
Copy link
Member Author

Choose a reason for hiding this comment

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

These are not implemented because Hibernate relies on PreparedStatement methods for batching.

@stIncMale
Copy link
Member

stIncMale commented Oct 22, 2025

Let's remove MongoStatement.executeUpdate(String) - Hibernate ORM does not use it. We should do it after dealing with the current PR.

Update: we decided to leave it, as removing it causes code restructuring (otherwise the code looks weird), and we don't want to do that. Continue having this method seems to be a lesser burden than removing it.


@ParameterizedTest(name = "test not supported update elements. Parameters: option={0}")
@ValueSource(strings = {"hint", "collation", "arrayFilters", "sort", "upsert", "c"})
void testNotSupportedUpdateElements(String unsupportedElement) {
Copy link
Member

Choose a reason for hiding this comment

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

These are not called "element", they are called "option". See https://www.mongodb.com/docs/manual/reference/command/update/. Let's make all the changes needed to reflect that.

The same applies to testNotSupportedDeleteElements.

Copy link
Member Author

@vbabanin vbabanin Oct 28, 2025

Choose a reason for hiding this comment

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

As discussed during the walkthrough - renamed to "field".

}

@ParameterizedTest(name = "test not supported update elements. Parameters: option={0}")
@ValueSource(strings = {"hint", "collation", "arrayFilters", "sort", "upsert", "c"})
Copy link
Member

Choose a reason for hiding this comment

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

I suspect, we should use both keys and values, like "hint: 'abc'", here, as otherwise the { _id: 1 } value currently used as the value of each option is not always valid. If we use a valid value for each option, then having an exception makes it more clear the the option name itself caused it.

The same applies to testNotSupportedDeleteElements.

vbabanin and others added 3 commits October 24, 2025 21:42
…redStatementIntegrationTests.java

Co-authored-by: Valentin Kovalenko <[email protected]>
…redStatementIntegrationTests.java

Co-authored-by: Valentin Kovalenko <[email protected]>
…redStatementIntegrationTests.java

Co-authored-by: Valentin Kovalenko <[email protected]>
Copy link
Member

@stIncMale stIncMale left a comment

Choose a reason for hiding this comment

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

Finished reviewing MongoPreparedStatementIntegrationTests. So far I have the following reviewed:

  • AbstractQueryIntegrationTests
  • LimitOffsetFetchClauseIntegrationTests
  • BatchUpdateIntegrationTests
  • MongoPreparedStatementIntegrationTests

We worked thoroughly on MongoPreparedStatement, MongoStatement during the code walkthrough. But I will still need to look at them once the changes are pushed.

The last reviewed commit is 11a2b07.

.returns(0, BatchUpdateException::getErrorCode);
} catch (SQLException e) {
throw new RuntimeException(e);
}
Copy link
Member

Choose a reason for hiding this comment

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

We don't need this catch (SQLException e) here and in any other test in ExecuteBatchTests.

Pre-existing test methods need it because they implement Function, while the new tests implement Work, and its Work.execute method throws SQLException.


@Test
void testBatchInsert() {
var batchCount = 3;
Copy link
Member

Choose a reason for hiding this comment

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

Maybe let's call it batchSize here and in other places? Feels more natural, and is closer to hibernate.jdbc.batch_size, which has the same meaning.

Neither JDBC API documentation, nor the JDBC specification seem to use "count" to refer to the number of commands in a batch.

Comment on lines 404 to 411
for (int i = 0; i < batchCount; i++) {
expectedDocs.add(BsonDocument.parse(format(
"""
{
"_id": %d,
"title": "Book %d"
}""",
i + 1, i + 1)));
Copy link
Member

Choose a reason for hiding this comment

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

Let's use for (int i = 1; i <= batchCount; i++), especially given that above we used these exact boundaries, so that we could use i, i instead of i + 1, i + 1. The same suggestion applies to testBatchUpdate.

}

@Test
@DisplayName("Test statement’s batch queue is reset once executeBatch returns")
Copy link
Member

Choose a reason for hiding this comment

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

The API documentation of PreparedStatement.addBatch calls it "batch of commands". I found "qeue" neither in the API documentation nor in the JDBC specification. Unless I missed it, and "queue" is the term that is actually used, let's say either "statement’s batch" or "statement's batch of commands".

vbabanin and others added 3 commits October 27, 2025 13:39
…redStatementIntegrationTests.java

Co-authored-by: Valentin Kovalenko <[email protected]>
Remove redundant tests.
# Conflicts:
#	src/main/java/com/mongodb/hibernate/jdbc/MongoPreparedStatement.java
#	src/test/java/com/mongodb/hibernate/jdbc/MongoPreparedStatementTests.java
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

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

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Copy link
Member

@stIncMale stIncMale left a comment

Choose a reason for hiding this comment

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

Almost done, but some more review work (or, rather, trying and maybe proposing) is needed in the area of exception handling and transaction handling. I continue reviewing.

Comment on lines +506 to +512
private static final Set<String> SUPPORTED_INSERT_COMMAND_FIELDS = Set.of("documents");

private static final Set<String> SUPPORTED_UPDATE_COMMAND_FIELDS = Set.of("updates");
private static final Set<String> SUPPORTED_UPDATE_STATEMENT_FIELDS = Set.of("q", "u", "multi");

private static final Set<String> SUPPORTED_DELETE_COMMAND_FIELDS = Set.of("deletes");
private static final Set<String> SUPPORTED_DELETE_STATEMENT_FIELDS = Set.of("q", "limit");
Copy link
Member

Choose a reason for hiding this comment

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

[optional]

What do you think about moving these to CommandDescription? That way the information tightly related to commands stays mostly there.

P.S. At first I thought about moving them there as instance methods, potentially with the checks, but then I realized that different commands have different structure (for example, aggregate does not have statements), which makes such endeavour non-trivial.

Copy link
Member

@stIncMale stIncMale left a comment

Choose a reason for hiding this comment

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

The last reviewed commit is afd8853 18a18f7, 515a8ac, 0a3ec1a.

I reviewed everything but:

  • MongoStatementTests
  • MongoPreparedStatementTests
  • the changes to MongoPreparedStatementIntegrationTests after 510bc2d (this commit and the changes before it were reviewed)

@vbabanin vbabanin requested a review from stIncMale October 30, 2025 20:48
@vbabanin vbabanin merged commit b8fb8b8 into main Oct 30, 2025
7 checks passed
@vbabanin vbabanin deleted the HIBERNATE-40 branch October 30, 2025 23:33
@vbabanin vbabanin restored the HIBERNATE-40 branch October 30, 2025 23:34
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 this pull request may close these issues.

3 participants