Realm-java: [Request]: Remove the block that stops primary key from being changed after object creation?

[MiralDesai]

Goal

What do you want to achieve?

I want the primary key to be editable, just like other objects, at least for the time being, while auto incrementing ids are not a feature in realm. They both go hand in hand.

---

Hey all,

I've just been trying to update to the latest version of realm, and came accross this issue, which for me at least requires a bit of a rewrite on how I deal with API responses. I had the weekend to think it over, and look at the PR for the feature that stops primary keys from being changed and I can at least understand but I think it was implemented too early.

It makes sense that primary keys don't change, however it's not something we should ever have to worry about. Esspecially as Zhuinden mentions in the PR (https://github.com/realm/realm-java/pull/3418): "I still think trying to set the same value as primary key shouldn't throw an exception, and is something that Realm should detect".

The reason I think it was implemented too early is because realm does not have auto incrementing ids for a primary key. This is a key feature that goes hand in hand with fixed primary keys. They should either both be implemented together or neither. (I know there's a workaround to create auto incrementing ids but it's just that, a workaround). I think some of the PR worries are valid concerns.

Just wanted to bring the discussion to light again in the hope something can be done. Ideally the best course of action is to add auto incrementing ids. If that's not possible because of Realm's Mobile sync feature, then I would say that the ability to change primary keys should be added back in.

Interested to hear your thoughts.

[cmelchior]

@MiralDesai Why do you need auto-incrementing ID's? See e.g https://github.com/realm/realm-java/issues/469#issuecomment-196798253

[MiralDesai]

I might not need it. It's just something I expect from a database to be honest. Even if I use or don't use the feature. The issue is that auto incrementing ids makes sense if you cannot change the primary key.

I personally get my primary keys from my server, already not ideal because I wanted them to be auto incrementing from the start, again just something I expected from a database, now that I cannot change the primary key I have to check if the primary key exists and then not edit the field if it does, but edit every other field related to that row.

[Zhuinden]

I would assume https://github.com/realm/realm-java/issues/4115 will help with auto-increment primary keys although lately I haven't had a single case where using an auto-increment key made sense, because afterwards you can't really find the object. I tend to make a String-based compound key instead.

[cmelchior]

@Zhuinden A CRDT Counter doesn't help with keys, it just guarantee that two counters on two devices eventually agree on the same value.

@MiralDesai It sounds like you fall into bucket 2) from the comment I referenced, In that case just add @PrimaryKey private String id = UUID.random().toString(); to your object. It will automatically generate a key for you. You do not have a need for auto-incremental ID's in that case.

[MiralDesai]

It's true I don't need auto incrementing ids, after some thought I probably don't need primary keys either since the primary keys are set on my server so I can assume they're unique. I suppose a random id is fine in that case.

From the perspective of realm as whole, do you think auto incrementing ids is not a feature that is needed then?

[cmelchior]

Yes, that is our general stance. Auto-incremental primary keys are alluring in SQLite because they are so easy to define, but they also suffer from limitations, the biggest being that they don't work in a distributed database across multiple devices. This conflicts with our design goals of being able to make Realm synchronise across devices by the flip of a switch.

As I described in the other issue, the 3 primary use cases can all be covered by other means.
That isn't to say there might exist a corner case where incremental ID's are what you want, and we should document a solution for that.

In general though, we should do a better job at documenting this as this question pops up fairly frequently (See #469)

It seems your question is answered, so i'll close this issue now.

[Zhuinden]

The problem in my opinion is that while auto-incremented IDs are essential in SQL-based relational databases so that you can create "JOINs" across the tables; in Realm, that is not how relations work, they are bound with links between the objects instead of manually joining them via primary key/foreign key matching.

So objects don't always need an autoincrement ID. If you use a @PrimaryKey in Realm, it's best if that ID is predictable, and can actually be used to identify the object - either by server response, or based on its data.

But generating UUID is easier to set up than manually finding maximum and id+1.

[MiralDesai]

I agree that the id should be identifiable. I think what I'll do is simply check if the object with that id already exists, if it does, I will not set the id again. Not something I thought I would have to deal with but it's fine, and makes the primary key useful.