https://kotlinlang.org logo
Join Slack
Powered by
also, another issue I'm stumbling upon is that kom...
# komapper
s
also, another issue I'm stumbling upon is that komapper renders CTEs with the list of resulting columns explicit in the statement (i.e. 
WITH <table name> (<column list>)
), but ClickHouse doesn't support the column list. Is there a way to modify this behavior, either through the dialect definition or otherwise, so that the resulting query omits the list of column names?
from what I gather from the code, this is not really possible, as 
SelectStatementBuilder
cannot be overridden by the dialect. This is probably going to be a roadblock for the integration with ClickHouse
d
I think the same thing could be done for select
s
From what I saw the library doesn’t get that from the dialect so it cannot be overridden. I guess it’s a relatively easy extension to build but it’s not there yet so it’s quite problematic for my timeline
d
Check out the various option flags in the dialect, it could be that the generation of what you're looking for is dependant on one of them.
When I was trying to make a dialect for mysql 5.7, I just had to override some of those options.
s
I will, tho I checked the code of SelectStatementBuilder and the inclusion of column names seems to be hardcoded and not configurable
d
This can be cut out:
Copy code
buf.append(" (")
                for (p in table.properties()) {
                    val columnName = p.getCanonicalColumnName(dialect::enquote)
                    buf.append(columnName)
                    buf.append(", ")
                }
                buf.cutBack(2)
                buf.append(") as (")
in private fun withClause() {
s
Yeah that’s what I saw as well, but how do you mean it can be cut out?
d
Yeah, I see, it's in the core module and the class isn't being passed in... there's an option per dialect for recursive, but none for that... it could be that @Toshihiro Nakamura might add such an option... but for now, it's either cloning the repo and making your own core... which isn't too nice, or finding a way to make your own 
with
to surround your query with.
t
ClickHouse seems to have its own syntax, different from standard SQL. I think it would be too difficult to support such SQL in Komapper Criteria API. Komapper provides SQL templates for dynamically assembling arbitrary SQL. How about using these? See https://www.komapper.org/docs/reference/query/querydsl/template/
s
Ok, I see. I saw templates already but it doesn't seem to be much more advanced than a plain jdbc prepared statement. I think that since the main use case for what I'm doing is building and running analytical queries with dynamic filters, I really would like to avoid raw sql
d
This is less of a big deal, since these criteria are pretty simple I'm sure you could just make a function with some kind of builder dsl just for that limited case... the real problem is in your other issue with the 
with
... of course, if there are too many differences, it's already not worth it to try, but if the syntax is mostly similar to a certain dialect with a few functions that are different, there's a lot to gain from all of Komapper's features.
s
agree with @dave08 here, in fact I somehow managed to get the criteria in my custom function so it's 99% there. But the issue with the CTEs is a showstopper for now. To be clear, I'd love to keep using komapper: the syntax is much cleaner than both exposed and jooq. But first priority is getting the job done so it depends on if and how fast the current behavior could be made configurable. I'm open on my side to contribute and open a PR if there's willingness to accept it
t
I will accept it. It would be sufficient to add a function in Dialect to determine whether to support the column list in the WITH clause.
s
ok that's great, I'll try my hand on that then
👍 1
btw, for the record, I tried to implement the same query with jooq (without code generation for now, so all identifiers are "manual" strings) and it worked without problems. I find though that the end result in terms of code is much less readable than with komapper, so I still plan to contribute that "fix" for the CASE statement. But I also have to say that I had to struggle much less due to the flexibility the design of the library provides compared to komapper (which has its pros and cons, for sure)
👍 1
Open in Slack
PreviousNext
Powered by