@Unique: replace on conflict flag

[greenrobot]

Right now, @Unique throws an exception if there's a violation.

We could also offer to replace old entities with newer ones, e.g. by doing a @Unique(replaceOnConflict = true).

Keep in mind: If there are multiple unique properties, on entity might replace several others.

[avcial]

Actually requirement is not completely replacing, just update fields which are not annotated as @id or @unique

[greenrobot]

@avcial Not sure if I follow. Example?

[kordianbruck]

@greenrobot you can update the fields instead of delete+create ("replace") objects that have a unique property (like primary keys and explicit @unique), but that's just an implementation detail. Difference is, that PKs will stay the same an FK will not break while updating a unique key with replaceOnConflict.

[avcial]

@kordianbruck you are soo right
As i mentioned before here, mine and in my opinion the most common case is that caching server datas to device for giving faster responses, but the necessity of UpdateOnConflict is that what if my users last name has changed but i don't want to lose my ObjectBox db ObjectId and relations on it.
Scenario :
Get datas from WebAPi you have empty table, you inserted all of them with logic [long id,string ServerGuid, string FirstName, string LastName].
Then you want to update your ObjectBox user table because you know you have some new users or some of your users might change their name or maybe they got married and their last name changed and you don't want to show old datas on your screen. So you get the new list from your api and then you give it to a function whic adds new users with new objectIds but it also checks the older records based on your second column(string ServerGuid) that is because your Server doesn't know ObjectBox ObjectId's of your devices and when you got data which are inserted before you just check the fileds(FirstName and LastName) which are not annotated by @id or @unique or maybe they are annotated on consciously like @UpdateOnConflict and update them with new datas which comes from the current entity.

[greenrobot]

Yeah, it makes sense to keep the ID, because it is used in relations and you do not want to cut those off.
So it should rather be @Unique(onConflict = UPDATE) with some enum {FAIL, REPLACE, UPDATE}.

We could extend further extend the enum with ABORT_TX (e.g. check SQLite ON CONFLICT).

HOWEVER, I'm getting doubts if it's a good idea to tie it to an annotation. Because annotations on two different properties could be contradicting. And also, behavior is less flexible.

The more flexible approach would be to overload the put method and pass either a ConflictResolution enum or flags (more hacky but more future proof) additionally.

[kordianbruck]

There is a bit more specific documentation in the SQLite docs: https://sqlite.org/lang_conflict.html

So yes, its a good idea and general industry standard when talking about SQLite based things: https://developer.android.com/reference/android/arch/persistence/room/OnConflictStrategy

Maybe SQLite is not the reference here, but I think when devs come from using an ORM like room, they at least expect similar ways how those things work 👍

[avcial]

I know the logic will be a mess but when you add the exception throwing on conflict at ver2.0.0 i expected that maybe you would return the original entity inside the error so we can do whatever we want to do with conflicted row, maybe try to put it again after some changes??

[greenrobot]

@kordianbruck Not sure what you are arguing for, could you explain? Do it as annotations? SQLite supports conflict resolution within column definition (inflexible), but also inside INSERT/UPSERT (flexible). I tend to prefer the flexible option, e.g. box.put(person, REPLACE) because at another code section you might want to do box.put(person, IGNORE) because you might have another use case.

@avcial Maybe be a mess for lists, but OK for single entities; e.g. Person conflict = box.putOrGet(person). Same with lists would be possible but you would loose the connection of offending and existing entity.

[avcial]

if performance is good enough it does't matter if i loose connection.
maybe the method will return me the list which is handled for the choosen strategy(ies)??

[kordianbruck]

@greenrobot sorry, I could've been more clear on that: I would vouch to use the same naming conventions as in SQLite for ROLLBACK, ABORT and FAIL so that developers coming freshly to objectbox already can guess what that flag is doing from their previous SQLite experience.

For our use cases we would be fine with annotated support. If the more flexible option is doable without modifying the API too much that also might be a good idea - no clue tho, how useful it is.

[avcial]

Throwing exception break's box.put(Collection ) method loop, there is a need for quick solution for that

[Mistic92]

Yep, I can't update via put method. I'm getting crash when entity with unique annotation exists but I just want to update

[avcial]

Any upgrade or time estimation?