Skip to content

simple DML translation #102

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

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

NathanQingyangXu
Copy link
Contributor

@NathanQingyangXu NathanQingyangXu commented May 27, 2025

https://jira.mongodb.org/browse/HIBERNATE-46

The scope of the ticket is to unblock the following simple DML HQL mutation queries:

  • insert into Book (id, title) values (1, "War and Peace"), (2, "Crime and Punishmnet")
  • update Book set title = "War and Peace" where title = "War & Peace"
  • delete from Book where title = "War and Peace"

Translation is straightforward. The following new visitor methods would be implemented in this PR:

  • void visitDeleteStatement(DeleteStatement deleteStatement);
  • void visitUpdateStatement(UpdateStatement updateStatement);
  • void visitInsertStatement(InsertSelectStatement insertSelectStatement);

Both of the first two methods share a lot in common in the sense that they are both based on where clause, with various AST filters as the backbones, which has been finished in previous PR.

The scope of this PR is modest and only focuses on the following basic stuff:

  • no new AST filter will be introduced
  • when updating, only $set updating operator is supported (with the constraint that $set focuses on field path and value pair)

One caveat is previously our insertion command mongo ast only allows one document, to fully support HQL's feature, the mongo ast model was refactored to allow multiple documents, consistent with MQL's syntax as well. There is a separate ticket for this requirment: https://jira.mongodb.org/browse/HIBERNATE-44, so we can finish it in this PR additionally.

@NathanQingyangXu NathanQingyangXu marked this pull request as draft May 27, 2025 18:17
});
}

public static final class MutateTranslatorAwareDialect extends Dialect {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

An important feature to test is we need to include the table names involved in DML queries into the result of SqlAstTranslator#getAffectedTableNames() which acts as auto-flush purpose in the upper level caller of the translator.

We might need to finish other features (like table joining) to test the auto-flush features in integration test; currently we could only test this important feature by some expedient.

@@ -36,17 +38,17 @@

@SessionFactory(exportSchema = false)
@ExtendWith(MongoExtension.class)
abstract class AbstractSelectionQueryIntegrationTests implements SessionFactoryScopeAware, ServiceRegistryScopeAware {
public abstract class AbstractQueryIntegrationTests implements SessionFactoryScopeAware, ServiceRegistryScopeAware {
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 class is reusable not only for select query but also for mutate query, so it is renamed and moved to more general location. The Book class was changed accordingly to go together with it hand in hand.

throw new FeatureNotSupportedException("Unsupported mutation statement type: "
+ mutationStatement.getClass().getName());
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

currently there is no fourth class of MutationStatement; the above last else clause is for future-proof purpose.

…t/command/AstInsertCommand.java

Co-authored-by: Jeff Yemin <[email protected]>
checkMutationStatement(insertStatement);
if (insertStatement.getConflictClause() != null) {
throw new FeatureNotSupportedException();
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

HQL has an interesting ON CONFLICT during insertion feature (see https://www.baeldung.com/hibernate-insert-query-on-conflict-clause). It is sort of similar to MongoDB's upsert feature but it seems there is a big difference between them:

  • HQL mainly focuses on conflict during insertion (w.r.t. unique constraint or fields combination); MongoDB's upsert focuses on conflict during updating (w.r.t. some query or filter,, e.g. comparison between a field and a value)

So I guess we can't support this HQL feature. HQL's update statement is simpler and provides no possibility to emulate MongoDB's upsert feature.

}
if (insertStatement.getSourceSelectStatement() != null) {
throw new FeatureNotSupportedException();
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

HQL has two flavours of insertion statement:

  • insert into Book (id, title) values (1, "War and Peace"), (2, "Crime and Punishment")
  • insert into Book (id, title) select c.identifier, c.name from Catalog as c

This PR will focus on the first variant and throw exception for the latter.

documents.add(new AstDocument(astElements));
}

astVisitorValueHolder.yield(COLLECTION_MUTATION, new AstInsertCommand(collection, documents));
Copy link
Contributor Author

Choose a reason for hiding this comment

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

there are 3 assertion usages above as follows:

  • insertion field list is not empty
  • insertion values list is not empty
  • field list length is the same as values length

The above constraints were either enforced from HQL grammar level or semantic checking phase in Hibernate (a prior step when the final SQL AST translation step is reached), so we can rest assured these constraints are enforced already.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

similarly, various assertions are used in updating case as well. Common constraints have been carefully centralized into checkMutationStatementSupportability() method. Only one checking is required to ensure the insertion field value or udpating field value expressions should be either valueExpression (literal value or parameter expressions).

throw new FeatureNotSupportedException();
}

var entityPersister = (EntityPersister) tableGroup.getModelPart();
affectedTableNames.add(((String[]) entityPersister.getQuerySpaces())[0]);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

the above visitFromClause will only be invoked for selection query, not for mutation query, though some common validation logic applies to both. For that reason, the logic is centralized in a new checkFromClauseSupportability() method

@NathanQingyangXu NathanQingyangXu marked this pull request as ready for review May 29, 2025 13:10
@NathanQingyangXu NathanQingyangXu marked this pull request as draft May 29, 2025 14:21
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.

2 participants