thank you @Alina Dolgikh [JB] 👏

set the channel description: SQL generation + experimental schema migration framework for Kotlin: https://github.com/mfwgenerics/koala

set the channel description: Koala is an SQL generation + experimental schema migration library for Kotlin: https://github.com/mfwgenerics/koala

hey @Damien O'Hara, is it possible to create custom operators if they don't exist? If someone wants to use the Postgres

ILIKE

but there's no support for it yet?

like with the custom type mappings

i'm assuming no though, not really sure how that would work

hey Ele. we don't support this at the moment but I'm happy to build it in. do you have any suggestions for how the API for custom operators might look?

maybe I could just make this type extensible rather than an enum: https://github.com/mfwgenerics/koala/blob/811e2ebbe7047576f7e858b77f995b799736e8fd/core/src/main/kotlin/io/koalaql/expr/OperationType.kt

that could work

although we'd need to know about

OperationFixity

?

fixity is how we internally decide whether operation

X

should produce sql expressions like

X(a, b)

,

X a

,

a X

,

a X b

etc

maybe that could be part of a superclass/function name for user defined ops? e.g.

class MyOp("ILIKE"): InfixOperation()

yep that would be good

okay cool. could you make an issue for this?

i'm also happy to make PRs to add Postgres specific operators as we come across them too

so it gets built out rather than all being done via custom mappings

yeah i will

yeah good idea

I am wondering if I'll need to split packages by SQL dialect at some point rather than putting all possible operations into the core package

yeah i was thinking that, everything looks to be in core atm

Bit of a weird question but how does koala decide to drop a table in a migration (if ever it does)? The code base is using

DeclareStrategy.APPLY_ALL

strategy +

MysqlDataSource

data source. We can see in the koalaql code base that we do attempt to pass the drop table changes into the actual reconciliation step Get generated changes ReconcileTables.kt

result
    .of(drop)
    .tables
    .dropped
    .addAll(changes.tables.dropped)

Apply changes JdbcDataSource.kt

is ReconcileTables -> applyDdlFromChanges(declareBy.filterChanges(
    changes = detectChanges(tables)
))

It just appears that for the MysqlDataSource we aren't generating the table drop changes which can then be applied (To be generated in MysqlSchemaDiff.kt)? What would the desired behaviour here be?

> Bit of a weird question but how does koala decide to drop a table in a migration (if ever it does)? In practice it won't. There is some machinery to drop tables if a removed table is part of a SchemaChange, but there is no mechanism for actually detecting a removed table in Koala and including it in a SchemaChange. See e.g. the MySQL SchemaChange stuff here: https://github.com/mfwgenerics/koala/blob/43d8c33ed73064b5c04ffb30f88714ee898b35d8/mysql/src/main/kotlin/io/koalaql/mysql/MysqlSchemaDiff.kt#L259 Part of the reason for this is that the list of tables passed into

detectChanges

is not considered to be exhaustive, so Koala can't use it to determine which tables have been removed (i.e. that might still exist, but simply weren't passed in to that method) In future I'd be open to some option for comparing an "entire" schema, but auto dropping tables is so dangerous I'd want to consider very carefully how this would be approached

Agreed, auto dropping is scary so would need to be deeply considered.