Max Asnaashari

@tomponline I think both approaches target different sorts of queries. For example, with slice fields, let's say we want to get all profiles with the names `"a"` or `"b"` or...

@tomponline I've now updated the generated `Get` functions to use variadic filter structs, each with a slice for their fields as well. so ```go []ProfileFilter{ {Name: []string{"a", "b", "c"}, Project:...

@tomponline @markylaing @stgraber If any of you have some opinions on this, I would appreciate it! There's also a draft PR #10946 that shows how this would work in practice...

> ```go > ```go > // A handwritten statement fetching all the certificates matching the project and fingerprint. > var certificateObjectsWithProjectIDByFingerprint = RegisterStmt(` > SELECT * FROM certificates > JOIN...

> An additional thing I've often wondered about the DB generator (given its aim is to reduce manually written boiler plate code) is why do we need to write define...

> > That particular statement will only execute if `filter.Fingerprint` is not nil. > > So I would have to define my custom SQL statements for every possible combination of...

> > No, `lxd-generate` is capable of parsing the non-filtered statement to produce filtered ones. So you would write `certificateObjectsWithProjectID` and then a generator comment with `objects-by-Fingerprint` would generate a...

I feel we're going on a bit of a tangent with the prepared statements, but they're actually a non-issue. Using the AST, if we have a reserved naming scheme for...

I'll lay out some examples here: A single handwritten query: ```go // A handwritten query. var certificateObjectsWithProjectID = RegisterStmt(SELECT...) // go:generate mapper stmt -e certificates objects-by-Fingerprint // go:generate mapper stmt...

As for making prepared statements optional, currently that behaviour is from parsing variable names of the form `Objects...` in the current package. We don't actually care if they're a call...