Open rdelossantos opened 9 years ago
@rdelossantos Yes, that will make sense. We should have a unique Column interface for this, I have generated the code for this, but want to wait until I figured out how to do the count(*), sum(age) and etc stuff.
Any suggestions, :)
For aggregate functions i believe it should be a simple string decorator:
Sum(field_var) => "sum(field_var)"
Ex:
objs.Select(User.Age, Max(User.Id)).Where(objs.FilterAge(">=", 10)).
GroupBy(User.Age)
Sum, Max, Min, etc. should concatenate the original field name and add the corresponding prefix and suffix for the sql aggregate function.
On execution it we'll return an error if a column is not grouped by and without aggregate function. Maybe in a later version it could be a more advanced feature with type safety.
From my point of view the library should be experimental before 1.0 release but should handle the 90% of tedious tasks like joins and aggregate functions.
From my point of view the library should be experimental before 1.0 release but should handle the 90% of tedious tasks like joins and aggregate functions.
Yes, definitely.
The SQL generating part is easy one, but in Select query, ModelQ will return a model struct which has all the typed data in it. But the count(x) or sum(x) is not part of the model struct which I think will need the join
to figured out first, :)
I'm too new to the Go Type system and i can't help for now, On next week i'll try to understand all the internals of the package, Thanks for your great work :).
I believe it should be a great feature if we can have struct tags generated for sql column names. Ex:
Should be:
Or
This is very important when you're designing big projects and you're refactoring the database models. The compiler we'll help to identify the errors after code generation from the refactored database.