Working on automatic migrations in Ktorm: https://github.com/kotlin-orm/ktorm-migration

it would be really cool if this was agnostic to orms (like ruby on rails migrations are. I don't know if djangos migration work only with djangos orm)

Each ORM requires its own kind of table definition, and since the whole point is to reuse the ORM's table definitions to generate migrations, making it ORM agnostic would take away a lot of the value.

Great! Was looking for this, using flyway right now. Might need to migrate from Exposed to Ktorm 😐

@ESchouten Glad someone else might use it! Just be warned that there's a lot to be done yet. I'm not entirely certain it is usable right now, as it isn't thoroughly tested and needs a lot of documentation. Since you've shown interest at least, I'll make sure I keep this channel posted on when it is. I can assure you it will be done at some point because my company needs it for our next project.

@joseph_ivie Thanks! I'll be keeping an eye on it, was yoyo-ing between Ktorm and Exposed anyways, time to do more research

Each ORM requires its own kind of table definition,.... making it ORM agnostic would take away a lot of the value.

well Ruby on Rails has pretty nice migrations that are orm agnostic, so thats debatable. but it seems to be tied to jdbc anyway and I would need something that supports r2dbc.

Fair enough - it would be nicer to run on something properly asynchronous. I chose Ktorm in the end merely because it was both well supported and I liked its API design. It might be possible to make it consume multiple kinds of table definitions (as in, from multiple ORM libraries) but I think in abstracting it you'd basically just end up rewriting it for each ORM anyways. Maybe I'm misunderstanding, but based on what I'm reading Rails's migrations are specific to its Active Record ORM?

in rails migrations are the history of table changes, and theres also a schema.rb(or sql) file that represents the current schema. each migration file consists of things like

change_table :users do
  add_field :user, :int
...
end

Cool, makes sense. Basically the same as what I did. Problem is Ktorm is the thing that translates that DSL into SQL right now, and migration generation comes from Ktorm-specific table declarations right now. The migrations could probably be separated out all right, but not the automatic generation of them. I think there's a Flyway that does migrations without autogeneration if that's what you're looking for.

makes sense. I know flyway but I would like something thats more dsl like, and uses kotlin.

liquibase has I think unofficial kotlin support

interesting, thanks!

It looks like ktorm is not as active on github as exposed... Although i also like it's api better...

That's kinda where I'm at after looking into Ktorm some more. The API might be better, but unfortunately, programming is frequently more about picking the thing that's used more often. Gradle might not exist if it weren't for that.

interesting

@ESchouten @dave08 Figuring you two in particular might like to know: After some deeper investigation, I've made some extensions to Exposed that clean up its API instead and I'll be moving the migration stuff over to it. https://github.com/lightningkite/exposed-plus

Looks interesting... I didn't like having to type up all those classes... and the current Entity type forces a dependency on all of exposed in the domain module since it requires an EntityId type... I'll have to see if I have a bit of time to pull out to try it 😉.

@joseph_ivie Very interesting! Using KSP for things like this seems promising. I myself am not sure if I would want library specific code in my domain models, but I see the opportunities it offers. Besides generating REST endpoints with security rules, another possibility could be Graphql endpoints + data fetchers I'm keeping my eye on this library!

I also don't like library specific code in the domain module... although it might be possible to overcome by using interfaces there, and implementing them in the data module with the annotations @ESchouten...?

@dave08 Interesting approach, definitely is one way to do it, though might add some overhead Just a quick thought: Perhaps we could reference the class in some table configuration DSL and reference ID fields/other fields needing special configuration in some reflective way.

@dave08 @ESchouten I was considering moving the annotations into their own package, so the domain module only has a dependency on a library with annotations only. Do you think that's good enough, or do you think total separation is necessary?

@joseph_ivie I guess for most people that would be fine, people use JPA as well after all. Personally, the philosophy I use, 'Clean Architecture', is a bit more strict, seeing the database implementation not as a key part of the application but rather as a detail, so using the annotations would go against the principle Example: https://github.com/ESchouten/CleanArchitecture

It makes sense. Bummer that makes it impossible to make a library like this then - foreign key class generation alone makes it not viable no matter how you would otherwise annotate the class in a separate file.

@joseph_ivie thinking again about this again, instead of annotating in the domain classes, couldn't we create a "Table configuration" class?

class UserTable : TableConfiguration(User::class) {
    override fun configure() {
        id(User::id)
    }
}

Might look weird, typed this on mobile

Yes, but what you can't do is the foreign key generation - I was using KSP to generate data classes representing foreign keys. Our company actually decided after some discussion to use Mongo instead, as it better fit what we were doing for our project, so unfortunately we won't be continuing on

exposed-plus

.