Another little question... if I have a long field ...

# komapper

[dave08]

Another little question... if I have a long field declaration (like a subquery) in my select statement and I want to order by it, it seems like Komapper copies the whole statement over into the order by produced (tested using dryRun)... is there any way to force-assign an AS foo to the field in select that it should use that in the order by?

[Toshihiro Nakamura]

It is not currently supported in regular queries. However, in UNION or UNION ALL queries, we do support specifying an alias in the ORDER BY clause.

val q1 =
    QueryDsl.from(e).where { e.employeeId eq 1 }
        .select(e.employeeId alias "ID", e.employeeName alias "NAME")
val q2 = QueryDsl.from(a).where { a.addressId eq 2 }
    .select(a.addressId alias "ID", a.street alias "NAME")
val query = (q1 union q2).orderBy("ID", desc("NAME"))

[dave08]

It seems like it does give the name specified in regular queries, I just wasn't aware of desc("aliasName"), I wonder if that works too n regular queries...

[dave08]

Maybe you mean it breaks something else like joins in regular queries?

[dave08]

Yup, in regular queries, you can't use desc("NAME") because there's no orderBy that takes in character sequences... is there any workaround for this @Toshihiro Nakamura?

[dave08]

Or maybe if I use with's instead of using the subqueries in the select statement...

[dave08]

I really would have expected that if q1 was passed in the select with an alias on the whole query, it would only appear in the select, but the alias would appear in the orderby.

[dave08]

Currently, if I do that, it seems to appear in both places WITH the AS... (which is not valid sql?)

[dave08]

This does seem to work:

private inline fun alias(
    alias: String
): ColumnExpression<String, String> {
    val name = "alias"
    return columnExpression({ it }, name, listOf()) {
        append("\"$alias\"")
    }
}

I use that in the orderBy... but it does surround the fields with (..), and it's not such a nice hack, but at least the sql is valid and the subqueries aren't repeated...

[dave08]

Well, after all this I really got stuck on joins not supporting sub-queries, which would have made a nice performance improvement in my complex sqls -- and there, there seems to be no workaround in the meantime...

I went back to templates again, but I guess it would be MUCH nicer if Partials could be on classes like I suggested in another thread... it would greatly simplify the parameters passed the main template... the only catch in this use-case is that I'd need to find a way to provide one of a few types of templates in the same slot... a filter could be based on Likes or Followers and each is a different template meaning I'd maybe pass an interface that they'd both derive from to the main command, and then use any of them (or null for none of them)... if you are thinking of implementing this, would that be possible?

[Toshihiro Nakamura]

I guess it would be MUCH nicer if Partials could be on classes like I suggested in another thread... it would greatly simplify the parameters passed the main template...

I will implement it in the next release.

the only catch in this use-case is that I’d need to find a way to provide one of a few types of templates in the same slot...

I’m probably not understanding the issue you’re facing. Could you provide a sample code?

[dave08]

sealed interface Criteria

@KomapperPartial("""...""")
class CriteriaByDateInterval(val startDate..., val endDate) : Criteria


@KomapperPartial("""...""")
class CriteriaByPopularity(val ...) : Criteria

@KomapperCommand("""
   ...
   /*> criteria */
""")
class GetFoo(val ..., val criteria: Criteria? = null)

@Toshihiro Nakamura

[dave08]

Instead of:

@KomapperCommand("""
   ...
   /*> criteriaByDate */ /*> criteriaByPopularity */
""")
class GetFoo(val ..., val criteriaByDate: CriteriaByDateInterval? = null, val criteriaByPopularity: CriteriaByPopularity? = null)

since anyways there can only be one of the two and not both...

[dave08]

In the generated code, there could probably be a when to test which instance of Criteria was passed down to resolve what needs to be interpolated in /*> criteria */ and since it's a sealed interface so there's only a limited number of implementations that can be listed by ksp (?) on the sealed interface... the only little thing, is that my use case has two levels of sealed interfaces and some are nested others not Criteria.Popularity.Likes vs Criteria.Likes (where Likes still inherits Popularity which inherits Criteria, but it's only nested in Criteria), which could complicate things...

[dave08]

This would be another great advantage over the const val version... since that can't have multiple implementations passed down...

[Toshihiro Nakamura]

Thank you for explaining your idea. I’ve created a pull request based on it. Please feel free to share any feedback you may have!
https://github.com/komapper/komapper/pull/1383

[dave08]

@Toshihiro Nakamura I commented on that Issue, thanks again!