LiteDB.LiteException: 'Cannot insert duplicate key in unique index '_id'. The duplicate value is '290'.'

[marcbarry]

I'm reporting this without a full understanding of the sequence of events which led to this condition so that it is captured. If it happens again I will back-fill with further detail.

The situation I encountered today with LiteDB (version 4.1.4) was inserting a record without setting the value of the Id field into a specific document collection started failing.

The code path for this insert hadn't changed in over 5 months, but inserting into one specific Collection in the LiteDB database stopped working earlier today. Calls to LiteCollection<T>.Insert(T document) started throwing the cited exception: LiteDB.LiteException: 'Cannot insert duplicate key in unique index '_id'. The duplicate value is '290'.'

For the document which was being inserted, the Id field was not specified so the document should have been inserted with an auto incremented value in the id field by the database engine.

As per the exception, record 290 already existed in the collection, so did 291, 292, 293 and so on, up to record auto-numbered at 304.

Accordingly, the expected behaviour is that LiteDB would insert the document with the Id field value auto-generated at 305, the next incremented value.

For want of a better term, I suspected LiteDB had somehow "lost count". I tried changing the code to explicitly set the Id field at 305, the value I was expecting auto-generated for the document the code was trying to insert.

This worked.

I then removed the Id field and tried another insert, relying on LiteDB to auto increment the Id field, which it started to do again - as I would have normally expected.

As I said, I'm not sure what led to this condition, but do suspect it to be a bug in LiteDB which is why I'm reporting this issue.

[Pokis]

Has this issue quite some times. I believe for our users it sometimes happens when they are writing something to the liteDB and the application crashes. I recently had an issue, where liteDB had last item with index 5524, and was giving exception on same insert, that item 5524 already exists (well yes, yes it does indeed). Deleting this row "revived" the db, and it started working again. It seems it caches up the _id of the db somewhere, but does not get updated during the crash, even though the actual data gets inserted.

We have this happening more than we like.

[mbdavid]

Hi guys, thanks for this feedback. Anyone can send me (in private) your database so I can checks whats going on? v4 persist last sequence using an attribute in Collection Page - but v5 works only with virtual sequence, getting highest value from collection.

[Pokis]

We are using v4. Sorry, I cannot share, I have only our user database which contains sensitive data that I am not allowed to share ;/.

[mbdavid]

So, if you are using v4, try insert manual highest value into your collection

[Pokis]

fixed mine by deleting and storing the same (latest) row again. Read on some other posts that other fixed exactly with the way you said.

[marcbarry]

Same for me @mbdavid - I cannot share the database, but I also did not keep a copy of the faulted version. Version 5 sounds like a good approach compared to version 4, however I'm sure there are trade offs which I don't appreciate.

What do you propose as a fix @mbdavid? The highest version I can see on nuget is 4.1.4.

Also, thank you so much for this fantastic project!

[mbdavid]

Hi @marcbarry, I have plans to release a new v4.1.5 with some fixes, but only after release v5 (I have lots of code/documentation to do).

[marcbarry]

Understood. Thanks @mbdavid, will look forward to it

[MidasLamb]

@mbdavid, I also ran into this issue. Is there any estimate for when v4.1.5 will be released?

[evmins]

@mbdavid Any plans for v 4.1.5? I have legacy project which uses .NET 3.5 and has to stay with version 4.

[okarpov]

still exist so far :( sad

[O-n-y]

still happens :( so sad is there is any workaround ?