-
Notifications
You must be signed in to change notification settings - Fork 245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change Resource - Index foreign key to SQLite ID #98
Comments
the index tables don't currently store the sqlite id directly. are you suggesting we add that as an additional column in each index table? |
Now A better way that be used is as following: The advantages of using databaseID + ResourceType includes: |
I would actually recommend we go with a local UUID instead as the key (can even ignore resource type). We can have a server id in addition to that to be used for server communications. FYI room 2.4 adds out of the box support for UUID (and saves it as a byte array). And for conflcits, we can simply ignore, it is super super unlikely to happen :) Also, keep in mind, sqlite ID (which i assume it referes to the auto-generated primary key), is a bit tricky to use. More specifically, if we ever do "insert(onConflict=REPLace)", sqlite will "Delete" the existing item and insert the new one, with a new id. this also means all fkey relationships will be deleted. (not different for UUID except it wouldn't be changing so with defferred fkey checks, we can handle that) |
|
Thanks for @yigit and @aditya-07 point out.
|
suggest we call these IDs |
Since
resourceID + resourceType
are 1:1 with SQLiteID
, it can be used as foreign key instead. This will save space in index tables.The text was updated successfully, but these errors were encountered: