Fixed
Status Update
No update yet.
Comments
mm...@commonsware.com
A similar scenario is using FTS3/FTS4 indexes, which also requires custom tweaking of the CREATE TABLE statement.
Since Migration already gives us the "escape hatch", is there a way we can use Migration to handle this case (e.g., consider a startVersion of 0 to mean we want to define the schema ourselves)? Or, perhaps add another property to @Entity that allows us to declare the SQL used to create the table?
Since Migration already gives us the "escape hatch", is there a way we can use Migration to handle this case (e.g., consider a startVersion of 0 to mean we want to define the schema ourselves)? Or, perhaps add another property to @Entity that allows us to declare the SQL used to create the table?
yb...@google.com
yb...@google.com
ya...@google.com
I suppose CREATE VIRTUAL TABLE (FTS3/FTS4) is out of scope for this issue (it's more than just column constraints), but we should consider supporting it.
I was wondering what to do with DEFAULT. Inserting/updating with @Query is fine, but for @Insert, how can we tell which columns to skip and let SQLite use the default value?
I was wondering what to do with DEFAULT. Inserting/updating with @Query is fine, but for @Insert, how can we tell which columns to skip and let SQLite use the default value?
bo...@gmail.com
I see that v1.0.0 Alpha 8 features "NOT NULL constraint is added for columns of primitive types or columns annotated with NonNull". That is great. But about about Kotlin?
ya...@google.com
It works with Kotlin too.
ma...@liulishuo.com
Then if I migrate from a database version which uses lower version of Room, I need to write large numbers of modify column to NOT NULL s ?
Description
Version used: 1.0.0-alpha1
Devices/Android versions reproduced on: Android Studio 3.0 Canary 1
There doesn't appear to be a way to add general SQLite column constraints [1] to the generated schema. In particular, my application uses NOT NULL and COLLATE NOCASE on some columns and I would like to be able to have Room generate entities with those clauses.
From what I can see there isn't any "escape hatch" to manually adjust the generated schema to workaround this issue.
1: