Supporting frameworks other than Exposed like ktorm

[ashokgelal]

Is your feature request related to a problem? Please describe.
It'd be nice to be able to use harmonica with frameworks other than Exposed without having to download extra dependencies.

Describe the solution you'd like
Write an abstraction adapter just like the way JDBC does for different databases.

[KenjiOhtsuka]

@ashokgelal
Thank you for your post. I will do that.
As for now, DbAdapter can be the candidate and I will make it usable from outside.

[KenjiOhtsuka]

@ashokgelal
I have a question.
Do you want to use ktorm? Or, could you provide a sample code which shows what you want to do?
(I thought I might have misunderstood your request.)

[ashokgelal]

Sure.
Well what I'm trying to achieve is using harmonica programatically via an API. I don't care about Maven/Gradle plugin. This use case is very similar to felipecsl/kales#12

A part of this use case is that since I'm using Ktorm and not Exposed, I'd like to be able to run migrations like so:

override fun up() {
        create(Departments)
}

Where Departments is a Ktorm table object.

I ran into a few of issues trying to use Harmonica programatically via an API:

1. There is no API
2. Setup was not only very difficult but for some reason it actually didn't work for me.
3. I did a fork to create a jar and used it that way.
4. I tried to do something similar to Add kales-cli db migrate task felipecsl/kales#12 but turns out you have changed some APIs since 1.1.18 by making some functions either internal or private. As a temporary solution I made them public again in my fork.
5. I'm sort of able to make it work but it all feels hacky. I wish the core was separate and hence I dropped this comment

I hope that makes sense.

I really believe that this library is great but I'm not a big fan the gradle plugin commands. I wish there was a core of harmonica I could use programatically. I was thinking of doing a hard fork and stripping out all the plugin cruft (and some other parts) but then I was too afraid to make that jump :)

Anyway, maybe you could find some time to make another library based on the spirit of Harmonica that is tightly integrated with Ktorm and I then I could make it a core dependency of a framework I'm working on :) I'm more than willing to offer my help and feedback.

Thank you for this awesome library!

[ashokgelal]

I ended up doing a hard fork and tailored it according to my requirements. Thanks to harmonica, I didn't have to do crazy refactoring. And thanks to you.

[KenjiOhtsuka]

@ashokgelal
I'm trying to tackle this issue. I think I have time to do this issue this and next week.

This is just an idea.
If the user create KtormMigration which inherits AbstractMigration, and put the method with a parameter of Ktorm class, it may work.

AbstractMigration class has method execute which receives any SQL String.

class KtormMigration : AbstractMigration
  fun create(ktorm: KtormObject) {
    // convert ktorm to SQL
    val sql = ...
    execute(sql)
  }
end

class M123_Migration : KtormMigration
  fun up() { ... }
  fun down() { ... }
end

I'm not familiar with Ktorm, so I have to study it.
This migration tool allows the user to use Exposed, but I think the current structure has a problem, because Exposed is downloaded regardless of whether the user uses Exposed or not.
Related: #91

Gradle command issue is another one. I'm wondering which is better.

As you can see, this library hides most of the innter classes with internal modifier. It is because I thought internal classes are not the business of library users and they may be something annoying.

Thank you for your collaboration.

[ashokgelal]

@KenjiOhtsuka I appreciate you trying to continue to work on it. But like I said, I have hard forked this and customize it according to my needs. If you want to check out how I've customized it, you can check it out here: https://github.com/alpas/alpas/tree/master/core/src/main/kotlin/dev/alpas/lodestar/migration

I don't want you to spend a bunch of time on modifying harmonica to fit my needs, as I'm probably not going to use it. However, if you are interested and have some time, even if it is in future, I'd love to have you collaborate with me on improving https://github.com/alpas/alpas/tree/master/core/src/main/kotlin/dev/alpas/lodestar/migration (I could use some help with tests and supporting Ktorm). I'd be more than happy to mention harmonica in the documentation. I'll let you decide, of course. :)