This is incidentally where .Net was around the 1.1 release (2003ish) We had code generation frameworks kicking out swathes of boiler plate.
Now Repository<T> and for us around 200,000 lines of code are gone and only one narrow set of tests to execute.
I guess I don't see how generics would help you reduce the number of insert/update functions. The basic problem of an ORM is to map struct fields to columns; I don't see how generics would help you here. Can you write the generic pseudocode you want to write?
I would guess something like:
class Collection<T implements Entity> {
void insert(T entity) {
String vals = entity.props.map(escapeSql).join(",");
String qs = entity.props.map(x => "?").join(",");
PreparedStatement p = db.prepare("insert into %s (%s) values (%s);", this.tableName, qs, vals);
db.submit(p);
}
}Go supports that today. Slice is a generic collection. Map will need to become for loops, but that's minor.
Re:Toward Go 2
by slantedview on Thursday July 13, 2017 @04:01PM
(#14764662)
The idea that we don't need generics because we can generate code is kind of ridiculous, and certainly doesn't pass the simplicity smell test.
He wasn't making that argument...
Re:Toward Go 2
by slantedview on Thursday July 13, 2017 @09:54PM
(#14766843)
Neither did I say he was. He was linking to a library that works around the lack of generics by generating code.
I would need one for each and every struct(table).
These days there is a tool that can generate all those struct methods: https://github.com/vattle/sqlboiler
So from the ORM perspective we (as the community) have worked around it.