simple DML translation #102

NathanQingyangXu · 2025-05-27T18:17:14Z

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 · 2025-05-27T18:19:32Z

...grationTest/java/com/mongodb/hibernate/query/mutate/AbstractMutateQueryIntegrationTests.java

+        });
+    }
+
+    public static final class MutateTranslatorAwareDialect extends Dialect {


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.

It is. related to auto-flushing criteria No..2 (see https://docs.jboss.org/hibernate/orm/6.6/userguide/html_single/Hibernate_User_Guide.html#flushing-auto):

prior to executing a JPQL/HQL query that overlaps with the queued entity actions

NathanQingyangXu · 2025-05-27T18:20:01Z

src/integrationTest/java/com/mongodb/hibernate/query/AbstractQueryIntegrationTests.java

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

 @SessionFactory(exportSchema = false)
 @ExtendWith(MongoExtension.class)
-abstract class AbstractSelectionQueryIntegrationTests implements SessionFactoryScopeAware, ServiceRegistryScopeAware {
+public abstract class AbstractQueryIntegrationTests implements SessionFactoryScopeAware, ServiceRegistryScopeAware {


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.

NathanQingyangXu · 2025-05-27T18:26:06Z

src/main/java/com/mongodb/hibernate/internal/translate/MutationMqlTranslator.java

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


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

src/main/java/com/mongodb/hibernate/internal/translate/mongoast/command/AstInsertCommand.java

…t/command/AstInsertCommand.java Co-authored-by: Jeff Yemin <[email protected]>

NathanQingyangXu · 2025-05-27T19:44:14Z

src/main/java/com/mongodb/hibernate/internal/translate/AbstractMqlTranslator.java

+        checkMutationStatement(insertStatement);
+        if (insertStatement.getConflictClause() != null) {
+            throw new FeatureNotSupportedException();
+        }


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.

I think we could support the same semantics in MQL.

1. "on conflict do update:

What HQL does:
insert … on conflict do update - checks a unique index; if the key is taken it runs the UPDATE clause.

What MongoDB does:
update … { upsert:true } matches a filter; if no doc matches it inserts instead.

Despite starting from opposite directions (insert-first vs. update-first) they end up with the same two-way branch:

Case HQL MongoDB

No existing row/doc run regular INSERT insert via upsert

Conflict / match found run DO UPDATE … run UPDATE …

We could put the “excluded” columns in $set, and use $setOnInsert for values present only on insert.
Example command:

{ updateOne: { filter: { _id: 1 }, update: { // similar to DO UPDATE … SET title = excluded.title $set: { title: "Pride & Prejudice" }, // fields present only on first insert $setOnInsert: { title: "Pride & Prejudice" outOfStock: false, publishYear: 1813, isbn13: NumberLong("9780141439518"), discount: 0.2, price: Decimal128("23.55") } }, upsert: true } },

2. "on conflict do nothing":

We could use ordered: false for insert operations to process all inserts and ignore any duplication errors reported via writeErrors. For this, though, we’d need to be aware of the HQL context, if possible.

In any case, I suggest we handle this as a separate ticket, so as not to block this PR and to keep the review focused. Let me know your thoughts.

Definitively it deserves a ticket. I think all of the following HQL criteria needs to be satisfied to allow for MQL translation:

ON CONFLICT is specified

ON CONSTRAINT uniqueIndexName is not used as the criteria (MQL's filter can't be based on unique index name, correct?)

CONFLICT ACTION is not NOTHING

so it seems the ticket is an interesting tech one but could be used very rarely in reality; native query seems more flixible and powerful.

I created a ticket here: https://jira.mongodb.org/browse/HIBERNATE-94. Let me know when you have any further suggestion.

NathanQingyangXu · 2025-05-27T20:25:22Z

src/main/java/com/mongodb/hibernate/internal/translate/AbstractMqlTranslator.java

+        }
+        if (insertStatement.getSourceSelectStatement() != null) {
+            throw new FeatureNotSupportedException();
+        }


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.

NathanQingyangXu · 2025-05-27T20:28:30Z

src/main/java/com/mongodb/hibernate/internal/translate/AbstractMqlTranslator.java

+            documents.add(new AstDocument(astElements));
+        }
+
+        astVisitorValueHolder.yield(COLLECTION_MUTATION, new AstInsertCommand(collection, documents));


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.

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).

…slator

...ionTest/java/com/mongodb/hibernate/query/mutation/AbstractMutationQueryIntegrationTests.java

src/integrationTest/java/com/mongodb/hibernate/query/Book.java

vbabanin · 2025-06-17T06:43:16Z

src/integrationTest/java/com/mongodb/hibernate/query/Book.java

-class Book {
+@Table(name = Book.COLLECTION)
+public class Book {
+    public static final String COLLECTION = "books";


Do we need this constant? Currently, tests fail if we change it because the collection name is hardcoded in the test assertions (which is okay, as it keeps the test self-sufficient and clear). I think we could stick to one approach - even if that means some duplication of string literals.

It is not necessary but still good to have. Either way is fine. But given we have renamed it, we need to change its references in the other testing cases.
I commited to fix the compiling issues.

...ionTest/java/com/mongodb/hibernate/query/mutation/AbstractMutationQueryIntegrationTests.java

vbabanin · 2025-06-23T06:32:40Z

src/main/java/com/mongodb/hibernate/internal/translate/AbstractMqlTranslator.java

+        if (fromClause.getRoots().size() != 1) {
+            throw new FeatureNotSupportedException("Only single root from clause is supported");
+        }
+        var root = fromClause.getRoots().get(0);


Currently, HQL joins are ignored without an exception being thrown. The root has a hasRealJoins method that detects when a join is present. Should we throw a FeatureNotSupportedException in this case, with a reference to HIBERNATE-65?

Good point. Adopted.

vbabanin · 2025-06-24T03:09:37Z

src/main/java/com/mongodb/hibernate/internal/translate/AbstractMqlTranslator.java

+        checkMutationStatement(insertStatement);
+        if (insertStatement.getConflictClause() != null) {
+            throw new FeatureNotSupportedException();
+        }


I think we could support the same semantics in MQL.

1. "on conflict do update:

What HQL does:
insert … on conflict do update - checks a unique index; if the key is taken it runs the UPDATE clause.

What MongoDB does:
update … { upsert:true } matches a filter; if no doc matches it inserts instead.

Despite starting from opposite directions (insert-first vs. update-first) they end up with the same two-way branch:

Case HQL MongoDB

No existing row/doc run regular INSERT insert via upsert

Conflict / match found run DO UPDATE … run UPDATE …

We could put the “excluded” columns in $set, and use $setOnInsert for values present only on insert.
Example command:

{ updateOne: { filter: { _id: 1 }, update: { // similar to DO UPDATE … SET title = excluded.title $set: { title: "Pride & Prejudice" }, // fields present only on first insert $setOnInsert: { title: "Pride & Prejudice" outOfStock: false, publishYear: 1813, isbn13: NumberLong("9780141439518"), discount: 0.2, price: Decimal128("23.55") } }, upsert: true } },

2. "on conflict do nothing":

We could use ordered: false for insert operations to process all inserts and ignore any duplication errors reported via writeErrors. For this, though, we’d need to be aware of the HQL context, if possible.

In any case, I suggest we handle this as a separate ticket, so as not to block this PR and to keep the review focused. Let me know your thoughts.

vbabanin · 2025-06-24T03:14:08Z

src/main/java/com/mongodb/hibernate/internal/translate/AbstractMqlTranslator.java

+            throw new FeatureNotSupportedException();
+        }
+        if (insertStatement.getSourceSelectStatement() != null) {
+            throw new FeatureNotSupportedException();


Let’s return a descriptive message here; otherwise, it won’t be clear to a user which feature isn’t supported.

src/main/java/com/mongodb/hibernate/internal/translate/AbstractMqlTranslator.java

vbabanin · 2025-06-24T03:37:35Z

src/integrationTest/java/com/mongodb/hibernate/query/mutation/InsertionIntegrationTests.java

+import org.junit.jupiter.api.Test;
+
+@DomainModel(annotatedClasses = Book.class)
+class InsertionIntegrationTests extends AbstractMutationQueryIntegrationTests {


Do we currently have a ticket to implement writeErrors handling as part of bulkWrite in executeUpdate?

At the moment, duplicate key errors on insert are not handled in executeUpdate, so it’s possible to insert two entities with the same ID without a specific error on the Hibernate side, even though the server returns a duplicate key error.

I think, before we switch executeUpdate to use bulkWrite instead of runCommand, we should add tests for duplicate inserts (annotated as @Disabled and linked to the relevant ticket) to ensure this logic isn’t missed during refactoring.

What do you think?

P.S Later, we may need to override buildSQLExceptionConversionDelegate in MongoDialect to handle exceptions.

We do have ticket to switch from runCommand to better alternative at https://jira.mongodb.org/browse/HIBERNATE-40, but there is no separate ticket to implement writeErrors.

I did experiment reproducing duplicated insertion as below:

@Test void testDuplicatedInsertion() { getSessionFactoryScope().inTransaction(session -> { var query = session.createMutationQuery(""" insert into Book (id, title, outOfStock, publishYear, isbn13, discount, price) values (1, 'Pride & Prejudice', false, 1813, 9780141439518L, 0.2D, 23.55BD) """); query.executeUpdate(); }); getSessionFactoryScope().inTransaction(session -> { var query = session.createMutationQuery(""" insert into Book (id, title, outOfStock, publishYear, isbn13, discount, price) values (1, 'Pride & Prejudice', false, 1813, 9780141439518L, 0.2D, 23.55BD) """); query.executeUpdate(); }); }

Below is the current stack trace:

Failed to commit transaction java.sql.SQLException: Failed to commit transaction at com.mongodb.hibernate.jdbc.MongoConnection.doCommitIfNeeded(MongoConnection.java:88) at com.mongodb.hibernate.jdbc.MongoConnection.commit(MongoConnection.java:78) at org.hibernate.resource.jdbc.internal.AbstractLogicalConnectionImplementor.commit(AbstractLogicalConnectionImplementor.java:87) at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:268) at org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:101) at org.hibernate.testing.orm.transaction.TransactionUtil.wrapInTransaction(TransactionUtil.java:54) at org.hibernate.testing.orm.transaction.TransactionUtil.inTransaction(TransactionUtil.java:24) at org.hibernate.testing.orm.junit.SessionFactoryExtension$SessionFactoryScopeImpl.inTransaction(SessionFactoryExtension.java:376) at org.hibernate.testing.orm.junit.SessionFactoryExtension$SessionFactoryScopeImpl.inTransaction(SessionFactoryExtension.java:353) at com.mongodb.hibernate.query.mutation.InsertionIntegrationTests.testDuplicatedInsertion(InsertionIntegrationTests.java:155) at java.base/java.lang.reflect.Method.invoke(Method.java:569) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) Caused by: com.mongodb.MongoCommandException: Command failed with error 251 (NoSuchTransaction): 'Transaction with { txnNumber: 2 } has been aborted.' on server localhost:27017. The full response is {"errorLabels": ["TransientTransactionError"], "ok": 0.0, "errmsg": "Transaction with { txnNumber: 2 } has been aborted.", "code": 251, "codeName": "NoSuchTransaction", "$clusterTime": {"clusterTime": {"$timestamp": {"t": 1750774932, "i": 2}}, "signature": {"hash": {"$binary": {"base64": "AAAAAAAAAAAAAAAAAAAAAAAAAAA=", "subType": "00"}}, "keyId": 0}}, "operationTime": {"$timestamp": {"t": 1750774932, "i": 2}}} at app//com.mongodb.internal.connection.ProtocolHelper.getCommandFailureException(ProtocolHelper.java:210) at app//com.mongodb.internal.connection.InternalStreamConnection.receiveCommandMessageResponse(InternalStreamConnection.java:520) at app//com.mongodb.internal.connection.InternalStreamConnection.sendAndReceiveInternal(InternalStreamConnection.java:448) at app//com.mongodb.internal.connection.InternalStreamConnection.lambda$sendAndReceive$0(InternalStreamConnection.java:375) at app//com.mongodb.internal.connection.InternalStreamConnection.sendAndReceive(InternalStreamConnection.java:378) at app//com.mongodb.internal.connection.UsageTrackingInternalConnection.sendAndReceive(UsageTrackingInternalConnection.java:111) at app//com.mongodb.internal.connection.DefaultConnectionPool$PooledConnection.sendAndReceive(DefaultConnectionPool.java:747) at app//com.mongodb.internal.connection.CommandProtocolImpl.execute(CommandProtocolImpl.java:61) at app//com.mongodb.internal.connection.DefaultServer$DefaultServerProtocolExecutor.execute(DefaultServer.java:208) at app//com.mongodb.internal.connection.DefaultServerConnection.executeProtocol(DefaultServerConnection.java:112) at app//com.mongodb.internal.connection.DefaultServerConnection.command(DefaultServerConnection.java:82) at app//com.mongodb.internal.connection.DefaultServerConnection.command(DefaultServerConnection.java:74) at app//com.mongodb.internal.connection.DefaultServer$OperationCountTrackingConnection.command(DefaultServer.java:298) at app//com.mongodb.internal.operation.SyncOperationHelper.lambda$executeRetryableWrite$10(SyncOperationHelper.java:267) at app//com.mongodb.internal.operation.SyncOperationHelper.lambda$withSourceAndConnection$0(SyncOperationHelper.java:131) at app//com.mongodb.internal.operation.SyncOperationHelper.withSuppliedResource(SyncOperationHelper.java:156) at app//com.mongodb.internal.operation.SyncOperationHelper.lambda$withSourceAndConnection$1(SyncOperationHelper.java:130) at app//com.mongodb.internal.operation.SyncOperationHelper.withSuppliedResource(SyncOperationHelper.java:156) at app//com.mongodb.internal.operation.SyncOperationHelper.withSourceAndConnection(SyncOperationHelper.java:129) at app//com.mongodb.internal.operation.SyncOperationHelper.lambda$executeRetryableWrite$11(SyncOperationHelper.java:252) at app//com.mongodb.internal.operation.SyncOperationHelper.lambda$decorateWriteWithRetries$12(SyncOperationHelper.java:308) at app//com.mongodb.internal.async.function.RetryingSyncSupplier.get(RetryingSyncSupplier.java:67) at app//com.mongodb.internal.operation.SyncOperationHelper.executeRetryableWrite(SyncOperationHelper.java:279) at app//com.mongodb.internal.operation.TransactionOperation.execute(TransactionOperation.java:60) at app//com.mongodb.internal.operation.CommitTransactionOperation.execute(CommitTransactionOperation.java:69) at app//com.mongodb.internal.operation.CommitTransactionOperation.execute(CommitTransactionOperation.java:48) at app//com.mongodb.client.internal.MongoClusterImpl$OperationExecutorImpl.execute(MongoClusterImpl.java:446) at app//com.mongodb.client.internal.ClientSessionImpl.commitTransaction(ClientSessionImpl.java:204) at app//com.mongodb.client.internal.ClientSessionImpl.commitTransaction(ClientSessionImpl.java:112) at app//com.mongodb.hibernate.jdbc.MongoConnection.doCommitIfNeeded(MongoConnection.java:86) ... 12 more

So it seems we can get clue from the root cause returned from Mongo Java driver?
What is your suggestion to improve on the current behaviour?

Yes, we can get more details from the root cause returned by the driver. The BulkWriteResult contains writeErrors, which includes error codes. Currently, when a transaction is aborted, the message doesn’t clarify what went wrong.

Hibernate ORM throws ConstraintViolationException for unique constraint violations - we should align with that behavior.

This can be achieved by handling writeErrors and throw an exception with the appropriate code. This can then be mapped in SQLExceptionConversionDelegate to the relevant Hibernate exception for user visibility.

When an exception is thrown from executeUpdate, Hibernate calls rollback on MongoConnection as expected, rather than attempting to commit a transaction that no longer exists.

Here’s a draft commit showing the relevant test and changes for illustration: 057bc0e

For this PR, I propose:

Add a test to cover ConstraintViolationException (to be disabled until writeError handling is implemented).

Throw SQLException with an error message and MongoDB error code, Hibernate should convert it to JdbcGenericException. Specific handling of write error codes can be addressed in a separate ticket during implementation of HIBERNATE-40.

I have created a separate ticket for proper implementation: HIBERNATE-95 later.

Let me know your thoughts.

Great!! That makes sense. I commit at 826df65. Further details like the exception message is better to be decided when we really start working on https://jira.mongodb.org/browse/HIBERNATE-95

…AbstractMutationQueryIntegrationTests.java Co-authored-by: Viacheslav Babanin <[email protected]>

Co-authored-by: Viacheslav Babanin <[email protected]>

…hanged in last commit

…AbstractMutationQueryIntegrationTests.java Co-authored-by: Viacheslav Babanin <[email protected]>

rename `assertExpectedAffectedCollections` to `assertAffectedCollections`

…s from mutation statement

…ion is thrown in InsertionIntegrationTests

…he old selection queries testing caeses

NathanQingyangXu marked this pull request as draft May 27, 2025 18:17

NathanQingyangXu commented May 27, 2025

View reviewed changes

NathanQingyangXu force-pushed the HIBERNATE-46 branch from 25d8fb7 to 8e2cee5 Compare May 27, 2025 18:36

jyemin reviewed May 27, 2025

View reviewed changes

src/main/java/com/mongodb/hibernate/internal/translate/mongoast/command/AstInsertCommand.java Outdated Show resolved Hide resolved

simple DML translation

55ab573

NathanQingyangXu force-pushed the HIBERNATE-46 branch from 8e2cee5 to 55ab573 Compare May 27, 2025 18:49

Update src/main/java/com/mongodb/hibernate/internal/translate/mongoas…

c4deaf9

…t/command/AstInsertCommand.java Co-authored-by: Jeff Yemin <[email protected]>

NathanQingyangXu commented May 27, 2025

View reviewed changes

NathanQingyangXu added 4 commits May 27, 2025 16:30

minor improvement to AbstractMqlTranslator#visitInsertStatement()

d71f568

minor improvements to AbstractMqlTranslator

1655c57

improvements to naming

163fb45

Merge branch 'main' into HIBERNATE-46

f8edea4

NathanQingyangXu force-pushed the HIBERNATE-46 branch from 42d2b77 to 5c7a58d Compare May 28, 2025 19:39

NathanQingyangXu marked this pull request as ready for review May 29, 2025 13:10

NathanQingyangXu requested review from vbabanin, stIncMale and jyemin May 29, 2025 13:10

NathanQingyangXu marked this pull request as draft May 29, 2025 14:21

NathanQingyangXu removed request for vbabanin and stIncMale May 29, 2025 14:21

NathanQingyangXu requested review from vbabanin and stIncMale June 10, 2025 20:30

NathanQingyangXu force-pushed the HIBERNATE-46 branch 2 times, most recently from 0cc0a35 to 4d24c09 Compare June 11, 2025 18:26

some improvements

6558ab1

NathanQingyangXu force-pushed the HIBERNATE-46 branch from 4d24c09 to 6558ab1 Compare June 11, 2025 18:29

validate affectedTableNames via translation result as opposed to tran…

164f433

…slator

stIncMale mentioned this pull request Jun 23, 2025

Limit/Offset/Fetch MQL translation #94

Merged

vbabanin reviewed Jun 24, 2025

View reviewed changes

NathanQingyangXu and others added 10 commits June 24, 2025 09:18

Update src/integrationTest/java/com/mongodb/hibernate/query/mutation/…

ed8eb06

…AbstractMutationQueryIntegrationTests.java Co-authored-by: Viacheslav Babanin <[email protected]>

Update src/integrationTest/java/com/mongodb/hibernate/query/Book.java

3cd06f7

Co-authored-by: Viacheslav Babanin <[email protected]>

fix compiling issues after the collection name constant in Book was c…

29b740f

…hanged in last commit

Update src/integrationTest/java/com/mongodb/hibernate/query/mutation/…

8e11fa9

…AbstractMutationQueryIntegrationTests.java Co-authored-by: Viacheslav Babanin <[email protected]>

Update src/integrationTest/java/com/mongodb/hibernate/query/mutation/…

41b1f10

…AbstractMutationQueryIntegrationTests.java Co-authored-by: Viacheslav Babanin <[email protected]>

fix compiling issue since last suggestion commit;

5217cc9

rename `assertExpectedAffectedCollections` to `assertAffectedCollections`

add description for FeatureNotSupportedException for returning column…

f6bd353

…s from mutation statement

add FeatureNotSupportedException when table joining is found

36a7d26

add descriptive messages to unsupported features in insertion statement

221ced3

add disabled testing case to track unique constraint violation except…

826df65

…ion is thrown in InsertionIntegrationTests

NathanQingyangXu requested a review from vbabanin June 25, 2025 13:58

NathanQingyangXu added 3 commits June 30, 2025 09:23

add affectedTableNames generic validation covering both new DML and t…

6eb6578

…he old selection queries testing caeses

Merge branch 'main' into HIBERNATE-46

90f8509

resolve conflict with latest main branch

9c35cf5

NathanQingyangXu marked this pull request as ready for review July 2, 2025 22:09

Case	HQL	MongoDB
No existing row/doc	run regular INSERT	insert via upsert
Conflict / match found	run DO UPDATE …	run UPDATE …

simple DML translation #102

Are you sure you want to change the base?

simple DML translation #102

Uh oh!

Conversation

NathanQingyangXu commented May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vbabanin Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

1. "on conflict do update:

2. "on conflict do nothing":

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vbabanin Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

1. "on conflict do update:

2. "on conflict do nothing":

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

vbabanin Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vbabanin Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

NathanQingyangXu commented May 27, 2025 •

edited

Loading

vbabanin Jun 24, 2025 •

edited

Loading

vbabanin Jun 24, 2025 •

edited

Loading

vbabanin Jun 24, 2025 •

edited

Loading

vbabanin Jun 24, 2025 •

edited

Loading