Upsert against db object behaves differently to upsert against batch about drift HOT 2 OPEN

The line you've referenced would actually be executed both for batches and for regular inserts, so I don't see how that should make a difference. I have slightly different line numbers so it's possible this changed recently, but both batch.insert and InsertStatement.insert call InsertStatement.createContext with the same arguments in the end, right?

Note: The reason I use the version of method with the onConflict callback, instead of insertOnConflictUpdate, is because I want to know if drift decided to do an update instead of an insert, so I can log the fact.

I don't think that's possible - we'll execute the callback either way to construct the update statement. The actual decision happens in the database, so the only way to be sure is to add a returning clause in SQL.

However, this logic is incorrect, as this is an update.

I agree with you here, but changing this now is also a subtle potentially breaking change. I think we should fix it in the next breaking release.

from drift.

Thanks @simolus3 - I'll build off a fork until then.

Regarding your statement about onConflict always being called - I didn't realise this - thanks.
I see that in SQLite, it's possible to do an INSERT... ON CONFLICT UPDATE... RETURNING * to determine whether the INSERT or UPDATE was executed (RETURNING * will return * on an INSERT, but nothing on an UPDATE)

Could I request we use this to avoid triggering the 'onConflict'? Or something else suitable for determining what an UPSERT resulted in?

Thanks

from drift.