IssueTracker

i forgot to mention that this is on android 2.2.

it doesn't actually return "max(id)" for the table.  it is literally, the last inserted rowid, which can also be 0 if you just opened the database after restarting the app.  lastInsertRow isn't thread safe anyway, so in conflict (all?) cases it seems best to just select based on the conflicting rows.

This line in the documentation is just plain wrong: "OR the primary key of the
        existing row if the input param 'conflictAlgorithm' =
        CONFLICT_IGNORE".

In 2.2 and 2.3, insertWithOnConflict() returns the result of sqlite3_last_insert_rowid(), which is not affected by failed inserts resolved by an ON CONFLICT-type clause.  The value returned is essentially meaningless because sqlite3_last_insert_rowid() is not thread-safe and in the case of ON CONFLICT inserts, it may return a row id from an unrelated insert.

In 4.0, insertWithOnConflict() returns the value of sqlite3_last_insert_rowid(), unless that value is 0, in which case it returns -1.  All the same problems still apply.

Fixing this is hard though, because I don't think SQLite3 provides a way to determine if the insert succeeded by adding a row or succeeded because the ON CONFLICT clause was exercised.  insertWithOnConflict() needs to return a row id (to maintain the current signature), but that simply isn't possible (AFAIK) with SQLite when using ON CONFLICT without just issuing a SELECT after the INSERT---and that could be seen as expensive relative to sqlite3_last_rowid().

After getting bitten by this bug earlier today, I've submitted a patch for this issue to AOSP, https://android-review.googlesource.com/#/c/53701/

[Comment deleted]

Seriously, why hasn't this been checked out yet. Causing me and my team a massive headache.

The patch is enough to at least prevent future developers from wondering why in the world it isn't working as documented.

Correct me please, if I'm wrong. But to me it seems like the patch still hasn't been applied (API level 20).

Why did this get marked obsolete? The issue still persists even in the latest API 22 SDK, since the patch from #4 was never applied.  
As someone who hasn't used the method in question before, it is highly confusing and needs time to go find the issue...

Sad that such a simple issue lingers around for nearly 4.5 years.

+One For Max Keller comment, this issue is still present!

I did my yearly rebase https://android-review.googlesource.com/#/c/53701/

So, is this solved or not ?

[Comment deleted]

The documentation is still incorrect.

As of May 2016 this bug hasn't been resolved even though it has been marked as Obsolete and is closed since Mar 2015

I just did my annual rebase and bump of the patch on gerrit.

It's marked as obsolete by project member. Chance for this bug being fixed is almost 0.

Actually, this time I was able to catch a reviewer's eye on gerrit and it got merged! I'm not sure how long it'll be until it shows up on the web.

5.5 years later, the documentation bug is finally resolved.

Ребята, ну это ни куда не годится, ё-маё.. столько лет прошло, а баг жив.