String ID aliases
Offer some convenience to use strings in an ID fashion.
I really hope this can be supported soon, love to try it out but having to use long id is quite troublesome
Would be really, really appreciated if this was added!
Any ETA? Month or week? I need to know this before public app release ;)
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)
any news about when will this be implemented?
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!
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; }
@obianachebe My workaround in kotlin:
fun String.toId(): Long = this.hashCode().toLong()
@Yazon2006 Dangerous thing to do. Hash collisions are quite likely.
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.
@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.
+1 for String Ids
expectation
+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
}
Can you please provide any time estimation for the String type ids implementation?
Is there a development message about this feature?
+1
+1
+1
Btw, a good in-between state is to use @Unique as introduced with ObjectBox 2.0.
@greenrobot
That's so Good
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.
@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 :)
@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"
@greenrobot So I must remove the entity with unique vin property and put again rather than can cover update it?
@linguokun1 They should at least put the already exist entity into exception instance.
@linguokun1 See https://github.com/objectbox/objectbox-java/issues/509 for current discussion.
+1
any news?
still waiting for..