Objectbox-java: String ID aliases

[greenrobot]

Offer some convenience to use strings in an ID fashion.

[thomasdao]

I really hope this can be supported soon, love to try it out but having to use long id is quite troublesome

[wirusw]

Would be really, really appreciated if this was added!

[Mistic92]

Any ETA? Month or week? I need to know this before public app release ;)

[vadimh77]

Hi guys,

It will great to support the string ids like other ORMs.

In the current situation if we get entities from the server that already exist in the DB then we don't know about it until making the call to the DB and finding these long ids and then copy them... (not a nice code)

[silviahisham]

any news about when will this be implemented?

[Yazon2006]

Of course there are some disadvantage in performance when string is used for primary key. But out of doubt such possibility should be. It's personal responsibility for everyone to use string as id or not. It's good if we have a choice what is more important performance or implementation speed. I wasn't able to use Room from google because it hasn't relations between entities. They explained that all relations should be handled on server side. It's true and it's best practice. But what if I'm not able to change server side because it's third part service. I'm pretty sure that some amount of people can't use ObjectBox because it can't handle string as id. Looking forward!

[obianachebe]

In the meantime, has anyone come up with a workaround for this? At the moment, all I can think of is to persist a separate id for MongoDB objects

EDIT
Looks like this is the recommended workaround from the docs:

If your application requires other ID types (such as a string UID given by a server), you can model them as standard properties and use queries to look up entities by your application specific ID.

@Entity public class User { @Id private long id; @Index private String serverUid; }

[Yazon2006]

@obianachebe My workaround in kotlin:
fun String.toId(): Long = this.hashCode().toLong()

[greenrobot]

@Yazon2006 Dangerous thing to do. Hash collisions are quite likely.

[Mistic92]

I was going to write the same. But for now, there is no other easy solution. Separate field for storing String id make a lot of mess and each time you need to check if it's not already in db.

[Yazon2006]

@greenrobot Of course I'm familiar with hash collisions. But in my case it's not a problem 'cause I have exhaustive amount of data in my db and there are no hash collisions. And also I hope that the feature with string id in objectBox will be available until release of my application.

[james-ff]

+1 for String Ids

[longforus]

expectation

[sandsaber]

+1
And my current workaround:
(Yeah, negative Id is still id, and work fine :) )

 fun longHash(string: String): Long {
        var h = 98764321261L
        val l = string.length
        val chars = string.toCharArray()

        for (i in 0 until l) {
            h = 31 * h + chars[i].toLong()
        }
        return h
    }

[vadimh77]

Can you please provide any time estimation for the String type ids implementation?

[a2open]

Is there a development message about this feature?

[ugurcany]

+1

[zhenxun815]

+1

[alijaza]

+1

[greenrobot]

Btw, a good in-between state is to use @Unique as introduced with ObjectBox 2.0.

[linguokun1]

@greenrobot
That's so Good

[thomasdao]

I can see @Unique is useful but it's not a replacement for String id. Let say if we want to sync the objects with string id from server, we would first need to query for existing object in local db then save or update the object in local db. I don't think it's performant approach, unless we load all the objects in db into memory so we can avoid the query for existing object.

[avcial]

@thomasdao +111111
Unfortunately we have to use server-Uniq-identifiers, this is the only way for us,
Please pretty please release this feature immediately.
God bless greenrobot :)

[linguokun1]

@greenrobot
when I want to update the same unique String vin property's entity, it throw : "Caused by: io.objectbox.exception.UniqueViolationException: Unique constraint for VehicleConfiguration.vin would be violated by putting entity with ID 2 because same property value already exists in entity with ID 1"

[linguokun1]

@greenrobot
So I must remove the entity with unique vin property and put again rather than can cover update it?

[avcial]

@linguokun1
They should at least put the already exist entity into exception instance.

[greenrobot]

@linguokun1 See https://github.com/objectbox/objectbox-java/issues/509 for current discussion.

[mesterj]

+1

[avcial]

any news?

[avcial]

still waiting for..

[TinoGuo]

no news?

[greenrobot]

We're getting closer; see https://github.com/objectbox/objectbox-java/issues/509#issuecomment-425055199

We are aware of the importance of this issue.

[avcial]

maybe not my bussiness but if you are afraid about limitless strings to produce identifiers, you may firstly consider UUID's as an elemtary type and make them indexable. Since lot's of developers uses Guid's as public indexes or tokens

[greenrobot]

Thanks for your suggestion. We prefer long IDs for efficiency. For sync, we use something like UUIDs internally (there's probably no use in exposing those).

[Sardoan]

For sync with other databases we would need the UUIDs. Seems you see the point in internal use, but using it for syncing with backend (uses UUID), iOS (uses UUID) and Android (with this DB long :( Beeing offline and using a long as id is no good idea. An UUID is the better way.

[VictorQueiroz]

This is a must for me, would be great if you could support that. Specially for those receiving objects coming from a MongoDB database. Unfortunately I'll have to stick with greenDAO for now until this is a supported feature.

[avcial]

still waiting for.....

[jesualex]

+1

[lucamtudor]

Any updates?

[andreiverdes]

What he said ^

[lucamtudor]

Are you guys actively working on this? This is a major pain-point for us!

We can't properly use relations in our models and let ObjectBox figure out when an object is new or needs updates, so we have to do a manual look-up each time we want to save something.

We used Realm & started migration to ObjectBox because of better API, better support for Architecture Components & no weirdness caused by the no-copy model. And because Realm is so damn slow at implementing features requested by the community (there still are a couple of issues from 2017 I'm still waiting for).

We're building a chat platform with lots of features that would benefit from ObjectBox's upcoming sync. But if I can't build the app today without making lots of error & bug prone workarounds there won't be a day when we'll happily pay for the sync service.

I moved away from SQL in 2014 and never looked back. Realm worked pretty well for not very complex scenarios & it was still better than writing tons of boilerplate code for SQL. ObjectBox came along at it seemed to be something even better, especially in the context of Android Architecture Components. But for a slightly more complex scenario that doesn't use Long ids, everything falls apart. I'm seriously considering going back to SQL. Room became a pretty solid library. It even supports suspend functions!

If the ObjectBox team is not interested in working on this, or has other priorities, just say so! Don't keep us waiting for months on end, for nothing.

Thanks, and sorry for the long & ranty message!

[vitaliecroitor]

Any updates regarding this issue?

The ToOne/ToMany solves only a part of the problem. Can we have an update strategy for relations?
Someting like: @OnUpdate(REPLACE).

Thanks!

[greenrobot-team]

Thanks for all the requests on an update. Our focus is currently on sync. And as always I can't give timelines, sorry.
-Uwe

[linuxanton-2469]

After two years of waiting, please give us a definitive timeline when string IDs will be implemented.

Customers are waiting for results. Otherwise i have to go back to SQL and never come back to Objectbox.

Regards
Anton

[mesterj]

Room is a very good alternative for objectbox.

[DaveBoy]

i get this issues before i use objectbox,it be created before 2years ago,i don't konw whether to choose it

[rustamsmax]

Are you going to solve this issue? We android developers don't have much more alternatives. At this time room sqlite is the best choice for us.