-
|
Describe the bug The wiki page on QRM says that you should be able to map a result to a struct purely based on the At least, that's the idea I got from this example in the wiki. But in the query below, this does not work, and I get an error about an unused column, since I turned on strict scan. So, using Any ideas? I really like the short form because it makes my query code a lot easier to read by reducing the boilerplate for queries that select lots of fields at once. FWIW I also tried declaring the field with Thanks again! Environment (please complete the following information):
Code snippet type ResultRow struct {
Name string
}
func ListExperiments(db *sql.DB, where BoolExpression) ([]ResultRow, error) {
stmt := SELECT(
Experiment.ExpID.AS("Name"),
).FROM(Experiment)
var dest []ResultRow
err := stmt.Query(db, &dest)
return dest, err
}var Experiment = newExperimentTable("", "experiment", "")
type experimentTable struct {
sqlite.Table
// Columns
ID sqlite.ColumnInteger
CtxID sqlite.ColumnString
ExpID sqlite.ColumnString
Dir sqlite.ColumnString
Experiment sqlite.ColumnBlob
Results sqlite.ColumnBlob
AllColumns sqlite.ColumnList
MutableColumns sqlite.ColumnList
DefaultColumns sqlite.ColumnList
}Expected behavior |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
As per qrm wiki: Destinations are not limited to just generated model types, any destination will work, as long as projection name corresponds to
In this example destination struct is anonymous type(no name). Meaning expected projection alias is This is also mentioned in faq. Without this rule, scanning into named nested types wouldn't be possible. |
Beta Was this translation helpful? Give feedback.
As per qrm wiki:
Destinations are not limited to just generated model types, any destination will work, as long as projection name corresponds to
model type name.field name.In this example destination struct is anonymous type(no name). Meaning expected projection alias is
.<field name>, which is equivalent to just<field name>.This is also mentioned in faq.
Without this rule, scanning into named nested types wouldn't be possible.