While converting my existing codebase to squirrel, I stumbled across something odd:
There is no way to use an Sqlizer with the OrderBy of a SelectBuilder. Afaik this should be valid SQL for most database implementations I can think of at the top of my head. To be more concrete, an OrderBy Sqlizer would enable e.g. to use a CaseBuilder for ordering.
I was about to hack together a quick PR, when I realized that this is not as easy to implement on the SelectBuilder side:
My first idea was to adjust the signature of OrderBy from OrderBy(orderBys ...string) to OrderBy(pred interface{}, rest ...interface{}), which would align with most of the other builder methods. Self-speaking, some adjustments to selectDatas toSql() included. However, this would utterly break existing code (especially because the new parameters are just interface{}s, so no compiler warning either). Also, the missing piece is where to put the order direction. Right now, what I have in my mind would look like this:
someSqlizer := ...
sql, args, _ := someSqlizer.ToSql()
selectBuilder.OrderBy(sql + " ASC", args)
... which is not very neat. On top of that, one would loose the ability to sort by multiple columns at once, and would have to resort to multiple OrderBy calls.
The other option would be the introduction of a new method, which just takes an Sqlizer. This would not break existing code, but would convolute the interface with an additional method for ordering. However, this option also suffers the missing ability to specify the order direction.
So... any thoughts? If a neat solution is decided on, I can probably cook up an PR to implement it.
Quick after tought: of course you can do someSqlizer.ToSql() and use the raw sql with OrderBy. However, this breaks if the sqlizer contains args, which are lost this way. And I really don't want to go the "replace placeholders myself" route.
While converting my existing codebase to squirrel, I stumbled across something odd:
There is no way to use an Sqlizer with the OrderBy of a SelectBuilder. Afaik this should be valid SQL for most database implementations I can think of at the top of my head. To be more concrete, an OrderBy Sqlizer would enable e.g. to use a CaseBuilder for ordering.
I was about to hack together a quick PR, when I realized that this is not as easy to implement on the SelectBuilder side:
My first idea was to adjust the signature of OrderBy from
OrderBy(orderBys ...string)toOrderBy(pred interface{}, rest ...interface{}), which would align with most of the other builder methods. Self-speaking, some adjustments to selectDatas toSql() included. However, this would utterly break existing code (especially because the new parameters are just interface{}s, so no compiler warning either). Also, the missing piece is where to put the order direction. Right now, what I have in my mind would look like this:... which is not very neat. On top of that, one would loose the ability to sort by multiple columns at once, and would have to resort to multiple
OrderBycalls.The other option would be the introduction of a new method, which just takes an Sqlizer. This would not break existing code, but would convolute the interface with an additional method for ordering. However, this option also suffers the missing ability to specify the order direction.
So... any thoughts? If a neat solution is decided on, I can probably cook up an PR to implement it.
Quick after tought: of course you can do
someSqlizer.ToSql()and use the raw sql withOrderBy. However, this breaks if the sqlizer contains args, which are lost this way. And I really don't want to go the "replace placeholders myself" route.