Hi! Is there support for having different Meta obj...
# komapper
d
Hi! Is there support for having different Meta objects for multiple database connections? It doesn't really make sense to put tables that are in db 1 into a db 2 Meta object and vise-versa...
t
Hello. Create multiple projects and set the name of the Meta object for each project. I have created a sample repository: https://github.com/nakamura-to/multiple-meta-objects-sample See also https://www.komapper.org/docs/reference/annotation-processing/#komappermetaobject .
d
Oh... I would need to split the two db definitions to two separate gradle modules...?
It would be a bit better to be able to specify this on the
@KomappperEntity
definition (which is the real place to decide to which db it's related...)
t
That’s a good idea. I will include that idea in the next version.
d
Though I wonder if there could be a way to prevent tables annotated for one db connection to only be usable with that connection (maybe having the name of the connection the same as what's entered in the entity annotation?). Also, it would probably be more practical for the library's users to make a custom annotation for each db like this:
Copy code
@KomapperEntity("db1")
annotation DB1Entity()
then use that in the entity's declaration, so that typos would be avoided...
t
I think that
@KomapperEntity(unit = Db1::class)
is good. I have implemented this idea. Feel free to give me your opinion. https://github.com/komapper/komapper/pull/794
d
Thanks for taking care of this so quick 👍🏼! I added a few comments to the PR there...
There couldn't be something like
Copy code
val db = JdbcDatabase<MyMetaObject>(config)
then the type could be used to validate and limit queries to it...?
And using my own annotation like this wouldn't be possible/efficient?
Copy code
@KomapperEntity(unit = Db1::class)
annotation DB1Entity()
t
The following utility class will help you achieve what you want to do:
Copy code
// Db1 is your meta object.
class Db1Access(private val db: JdbcDatabase, private val meta: Db1) {
    operator fun <T> invoke(block: (JdbcDatabase, Db1) -> T): T {
        return block(db, meta)
    }
}
The above class is used as follows:
Copy code
val db1Access = Db1Access(db, Db1)
val result = db1Access { db, meta ->
    val a = meta.address
    db.runQuery {
        QueryDsl.from(a).where { a.id eq id }.first()
    }
}
```@KomapperEntity(unit = Db1::class)
annotation DB1Entity()```
Unfortunately, this style is not efficient.
d
The following utility class will...
Yeah, I guess, just with one extra level of nesting...
Unfortunately, this style is not efficient.
Wow, I would have thought that compile-time KSP would handle such things easily... I wonder if there would be any other way to make this less error-prone and verbose. It's not a tremendously big deal... it's already better than what it is now, but still...