implement loading by primary key

[NathanQingyangXu]

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

The first "select statement" translation ticket, though the simplest one (where clause only contains primary key equalness comparison). Very business logic intensitve PR.

I added comments to explain the various edge cases of business logic and hope that would help.

[NathanQingyangXu]

after further investigation, it seems we can rule out the above possibility (only table updating has such concern for some reason), so I deleted it to avoid long-term potential confusion.

[stIncMale]

only table updating has such concern

What is that "table updating", and why it can never happen to us? Also, if we can see why it can never happen, but it's a thing nevertheless generally speaking, we should leave an explicit assertion, informing a reader that we did not miss the case when columnValueBinding.getValueExpression() is null, but thought about it and claim that it will never happen to us.

[NathanQingyangXu]

Below is the scenario that columnValueBinding.getValueExpression() could be null (https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core/src/main/java/org/hibernate/sql/ast/spi/AbstractSqlAstTranslator.java#L8745C6-L8745C58):

                       if ( tableUpdate.getNumberOfOptimisticLockBindings() > 0 ) {
				tableUpdate.forEachOptimisticLockBinding( (position, columnValueBinding) -> {
					sqlBuffer.append( " and " );
					sqlBuffer.append( columnValueBinding.getColumnReference().getColumnExpression() );
					if ( columnValueBinding.getValueExpression() == null
							|| columnValueBinding.getValueExpression().getFragment() == null ) {
						sqlBuffer.append( " is null" );
					}
					else {
						sqlBuffer.append( "=" );
						columnValueBinding.getValueExpression().accept( this );
					}
				} );
			}

The reason is the requirement of SQL's special nullness syntax (i.e. xxx is null), so if columnValueBinding.getValueExpression() is a parameter placeholder, there is no accommodation of the nullness SQL requirement or not easy; for insertion case, there seems no such possibility, so that is why I claimed that we might be able to remove the unnecessary nullness checking.

So it seems it doesn't hurt to retain the nullness checking in insertion case. I reverted it back.

[NathanQingyangXu]

CTE (Common Table Expression; See https://hightouch.com/sql-dictionary/sql-common-table-expression-cte for a gentle introduction to CTE) is about creating some temporary table. Mongo aggregate command seems to support it, but for this PR let us throw exception for now.

[NathanQingyangXu]

QueryPart has two child classes:

• QueryGroup
• QuerySpec

The latter will be covered in the visitor method below; QueryGroup is used for a set of QuerySpec and how to combine them together. A typical example is as follows:

SELECT column_name(s) FROM table1
UNION
SELECT column_name(s) FROM table2;

[NathanQingyangXu]

a subquery example:

select d from Department as d where d in (select s.department from Salesperson s where s.name = ?1)"

[NathanQingyangXu]

An example HQL in which there are multipe roots:

select li.id from LineItem li, Product as p where p.id = li.product.id and li.quantity >= ?1 and p.name = ?2

[NathanQingyangXu]

tableGroup's modelPart doesn't necessarily corresponds to an entity table (EntityPersister class corresponds to it), for instance, for @OneToMany association, the collection field will have its SQL translated and its model part will be a special PluralAttributeMappingImpl class object containing foreign key specific logic.

When model part is an EntityPersister corresponding to an entity, not entity collection, there could be the possibility that the entity class hierarchy ends up with multiple tables (getQuerySpaces() will return all the relevant table names during query) corresponding to the "joinied table" mapping option (see https://docs.jboss.org/hibernate/orm/6.6/userguide/html_single/Hibernate_User_Guide.html#entity-inheritance for details)

[NathanQingyangXu]

There is some edge case that some SqlSelection entry exists for some reason but are not meant to be used in SQL. For such virtual entries, we simply ignore during SQL translation (a pattern also in AbstractSqlTranslator).

[jyemin]

Just did an initial pass of the core functionality, and had a few comments.

[stIncMale]

Partial review results. I am submitting them only because it's the only way to leave a comment in an existing discussion.

[stIncMale]

The review hasn't been completed. Leaving partial results again to comment on an existing discussion.

[stIncMale]

I started thinking on which of the classes we plug in Hibernate ORM have to be thread-safe, and which are used multiple times - it's not obvious, and is, of course, not documented by Hibernate ORM.

1. MongoDialect - only one instance is created. Does this mean it has to be thread-safe, or does Hibernate ORM guarantee not to use it concurrently?
2. MongoTranslatorFactory - essentially, Hibernate ORM uses a single instance, but creates two due to this sloppy code. As far as I understand, this instance should be thread-safe.
3. SqlAstTranslators created by MongoTranslatorFactory
   3.1. It looks like a new instance of SelectStatementMqlTranslator is created for each query that is different in any way from those previously translated, even if the difference is in QueryOptions. Furthermore, SelectStatementMqlTranslator.translate is called only once per instance of SelectStatementMqlTranslator. That is, it looks like SelectStatementMqlTranslator does not need to be thread-safe, nor does it need to be reusable, i.e., we are fine with making it stateful and not resetting the state before returning from the SelectStatementMqlTranslator.translate method.
   3.2. Is the same true about all translators created by MongoTranslatorFactory?
4. StandardServiceRegistryScopedState.ServiceContributor.contribute - may be called multiple times if multiple instances of StandardServiceRegistry are built.
5. MongoAdditionalMappingContributor - TODO for @stIncMale.

We should document (for ourselves) the above, provided that the above is correct. @NathanQingyangXu, do you think the above assessment is correct?

---

A similar thing is about the SPI we expose:

1. MongoConfigurationContributor - its method configure is called once per building an instance of StandardServiceRegistry. We should document this, because this affects both reusability requirements applied to implementations, and only an application author may figure out based on the application whether his MongoConfigurationContributor has to be reusable.

I created PR 76: Add MongoConfigurationContributor tests and document it better to address this part.

---

With our JDBC implementations things are simple, because we are familiar with the JDBC API, and are not familiar with the Hibernate ORM extension API, which is not documented extensively - none of them are used concurrently, i.e., they don't need to be thread-safe.

[NathanQingyangXu]

I think what you think is correct, except for the point to create multiple StandardServiceRegistry instances (I explained about it below).

As a general rule, all those class related to global configuration will end up with singleton instance (similar to Spring bean). Technically these classes are not thread-safe and it is developer's responsibility to ensure thread-safety (e.g. Dialect singleton instance could be accessed from different concurrent sessions at the same time), but usually these classes don't maintain their own state and is read-only in essence, so it is very rare to see concurrency related stuff is there.

Only for the global SessionFactory scope, concurrency is a relevant concern (like QueryPlan cache, which is based on double lock checking to ensure thread-safety).

Yeah, JDBC APIs will be used in Session which is thread-safe, so we don't need bother with concurrency issue in JDBC layer.

The various translators would be created dynamically as the following javadoc implies (by single-use verbiage):

/**
 * Factory for obtaining single-use SQL AST translators
 *
 * @author Steve Ebersole
 */
public interface SqlAstTranslatorFactory {
	/**
	 * Builds a single-use select translator
	 */
	SqlAstTranslator<JdbcOperationQuerySelect> buildSelectTranslator(SessionFactoryImplementor sessionFactory, SelectStatement statement);

	/**
	 * Builds a single-use mutation translator
	 */
	SqlAstTranslator<? extends JdbcOperationQueryMutation> buildMutationTranslator(SessionFactoryImplementor sessionFactory, MutationStatement statement);

	/**
	 * Builds a single-use delete translator
	 *
	 * @deprecated Use {@link #buildMutationTranslator(SessionFactoryImplementor, MutationStatement)} instead
	 */
	@Deprecated(forRemoval = true)
	default SqlAstTranslator<JdbcOperationQueryDelete> buildDeleteTranslator(SessionFactoryImplementor sessionFactory, DeleteStatement statement) {
		//noinspection unchecked
		return (SqlAstTranslator<JdbcOperationQueryDelete>) buildMutationTranslator( sessionFactory, statement );
	}

	/**
	 * Builds a single-use insert-select translator
	 *
	 * @deprecated Use {@link #buildMutationTranslator(SessionFactoryImplementor, MutationStatement)} instead
	 */
	@Deprecated(forRemoval = true)
	default SqlAstTranslator<JdbcOperationQueryInsert> buildInsertTranslator(SessionFactoryImplementor sessionFactory, InsertStatement statement) {
		//noinspection unchecked
		return (SqlAstTranslator<JdbcOperationQueryInsert>) buildMutationTranslator( sessionFactory, statement );
	}

	/**
	 * Builds a single-use update translator
	 *
	 * @deprecated Use {@link #buildMutationTranslator(SessionFactoryImplementor, MutationStatement)} instead
	 */
	@Deprecated(forRemoval = true)
	default SqlAstTranslator<JdbcOperationQueryUpdate> buildUpdateTranslator(SessionFactoryImplementor sessionFactory, UpdateStatement statement) {
		//noinspection unchecked
		return (SqlAstTranslator<JdbcOperationQueryUpdate>) buildMutationTranslator( sessionFactory, statement );
	}

	/**
	 * Builds a single-use translator for dealing with model mutations
	 */
	<O extends JdbcMutationOperation> SqlAstTranslator<O> buildModelMutationTranslator(TableMutation<O> mutation, SessionFactoryImplementor sessionFactory);

}

I failed to see the necessity of multiple instances of StandardServiceRegistry. It should be created as singleton for one SessionFactory as well.

[NathanQingyangXu]

If our user is tech-savy, I think such doc might only end up with confusion.

[NathanQingyangXu]

sorry, if the doc is for our own side, go ahead

[NathanQingyangXu]

Thanks for raising the awareness of the duplicated SqlAstFactory creation issue in JdbcEnvironmentImpl. I'd created a PR and it got merged at hibernate/hibernate-orm#9900 already.

[stIncMale]

Factory for obtaining single-use SQL AST translators

I was looking for a piece of doc like that, but missed it. Thank you for pointing to it!

I'd created a PR and it got merged at hibernate/hibernate-orm#9900 already.

Great! I'll create a ticket making MongoTranslatorFactory a singleton, as we won't get that fix in Hibernate ORM 6.x.

I'll also create a PR addressing the rest of internal documentation changes mentioned here.

[stIncMale]

The last reviewed commit is 4fca70d.

[NathanQingyangXu]

P.S. I struggle to understand why situations like this keep happening quite often. Was the first comment I left actually so indecipherable, or was it not read carefully?

It is mainly due to the knowledge gap from my side. I didn't know of the subtlety of contact.phone.number until I experiemented locally and afterwards read the relevant mongo doc.

[stIncMale]

The last reviewed commit is 4a165c6.

[stIncMale]

The last reviewed commit is c779cfd.