Feature request: generated bind method for model objects on prepared statements
See original GitHub issueIf I have a parametric statement that only consists of fields from one object, it would be nice if SqlDelight generated a bind
overload that took a MyTableModel
as a parameter to populate the fields. Example:
CREATE TABLE someTable (
_id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
someString TEXT,
someInteger INTEGER
);
insertThing:
INSERT INTO someTable (someString, someInteger) VALUES (?, ?);
Could generate a SomeTableModel.InsertThing
class with a method like:
public void bind(@NonNull SomeTableModel model) {
bind(model.someString(), model.someInteger());
}
This would be helpful for cases where you have a lot of parameters where you really just want to insert all the fields from a model impl. Currently this becomes really verbose and potentially error-prone if you have a lot of fields to insert.
The main thing for me at least would be INSERTs and UPDATEs. You might consider applying it to any type of SQL query (e.g. a SELECT from 2 tabes might take two parameters to supply the parameters for fields from the respective table). Of course this is only useful if you assume that every parameter should be mapped to its corresponding field - maybe this is questionable for SELECTs. Even for UPDATEs, it’s questionable if it should correspond to fields in a WHERE clause, so perhaps that should be separate parameters, etc.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:7
- Comments:9
Top GitHub Comments
I was just looking for the same thing as the OP and was surprised I didn’t find it in generated code.
I understand all the arguments, but my usecase is the following: I have a table with 24 columns and currently when inserting new objects (I use
insert or replace
) I have to manually destructure a model to pass all those properties to abind
method.This is surely doable, but it’s a bit error prone, I could accidentally swap some column names (during some refactoring for example).
It would be great if code generation would help me to stay on the safe side in this case 😃
I’d prefer the syntax suggested by @AlecStrong over here #505, since it’s not really a tuple that you’re inserting: