-
|
Why isn't I want to convert the value of a Also, as my ultimate goal is to get the value of a column as a Thank you! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
Hello @mallman,
This is because
try db.create(table: "myTable") { t in
t.column("a", .boolean) // 1
t.column("b", ColumnType(rawValue: "BOOL")) // 2
t.column("c", ColumnType(rawValue: "PIKACHU")) // 3
}All of them are valid ways to declare columns that store booleans. 2 is original but quite OK; 3 is confusing but it won't create any runtime problem at all. That's how Datatypes In SQLite work. The library does not provide any interpretation of raw column types returned by If an application wants to perform a specific handling of columns with type "BOOLEAN", that's ok: To my eyes, the |
Beta Was this translation helpful? Give feedback.
-
There exists try db.create(table: "myTable") { t in
t.column("flag", .boolean)
}
let sql = "SELECT flag from myTable"
let statement = try db.makeStatement(sql: sql)
if let type = sqlite3_column_decltype(statement.sqliteStatement, 0) {
print(String(cString: type))
} else {
print("unknown")
}The above snippet prints "BOOLEAN". Add the NOT operator: "SELECT NOT flag from myTable". Now it prints "unknown". So it won't bring us very far.
Yes. We can't do much more with the information provided by SQLite. Instead of switching on the storage of a if dbValue.isNull {
// Handle NULL
} else if let bool = Bool.fromDatabaseValue(dbValue) {
// We were able to decode a bool, but that's all that we know.
} else {
// Definitely not a bool
} |
Beta Was this translation helpful? Give feedback.
-
|
Hi @groue. I believe I understand your reply, and it makes sense. Rather than introspecting on the SQLite column info type, how about introspecting on the GRDB migration schema? As a matter of API the user designs and defines the migrations. They provide a column type annotation of their choosing. It can be one of the convenient pre-defined values, or it can be "PIKACHU", et. al. The point is, they control what they put in there. They should be able to identify it when introspecting a table migration. Is it even possible to introspect on the schema definition? I don't see it stored in the table, and defining a stable serialized form for it may be a major pain in the ass. Another possibility is I can probably introspect on the Swift type of the At any rate, for my purposes, assuming the value of |
Beta Was this translation helpful? Give feedback.
-
Basically yes. On top of that, add the first sentence of the GRBD documentation for the database schema, written in bold:
🎵 Come as you are 🙂. I care a lot about this. Some people ship ready-made databases as resources in their app, and god knows where the db comes from 😅. The same document goes on with some recommendations, though, as few as it was possible. Each one of them has a rationale, and a way to deal with deviations (so that really all schemas are supported). The SQL type of boolean columns is not mentioned because there is no GRDB feature that depends on it.
The only serialization of migrations I know is the Swift files that define them 😉 Maybe SPM plugins and Swift syntax can do miracles. For an example of a Swift SQLite package that uses plugins for introspection, see Lighter. At runtime, an app can use the schema introspection methods which provide as much information as SQLite provides (i.e. strings). An app can also parse the results of
Yes. I think that you can decide that your app only works with |
Beta Was this translation helpful? Give feedback.
Hello @mallman,
This is because
ColumnTypeis a type dedicated to schema definition, not to schema introspection.ColumnTypeprovides ready-made constants for frequently used column types:.integer,.text,.boolean, etc. But it is not an enum. It is a struct. SQLite accepts about everything as a column type. For example, consider those three columns:All of them are valid ways to declare columns that store booleans. 2 is original but quite OK; 3 is…