https://kotlinlang.org logo
#komapper
Title
# komapper
d

dave08

01/15/2023, 1:41 PM
It might also be nice to generate a list or set of all of the contents of each Meta object in the Meta object. Often one would like to just create or drop all the tables in tests, and manually managing such a list is a bit error prone and extra boilerplate.
t

Toshihiro Nakamura

01/15/2023, 2:39 PM
We had the same discussion here: https://github.com/komapper/komapper/issues/681
d

dave08

01/15/2023, 2:53 PM
I'm not sure if this is a better solution, but I added a comment there: https://github.com/komapper/komapper/issues/681#issuecomment-1383170621
@Toshihiro Nakamura Did you have a chance to see this comment? Maybe making the generated entity meta classes to derive from a sealed class would be simpler, and then it would be easy to retreive all those tables from a particular Meta object...
I bit hard to discuss things in a Github issue, I can summarize concusions thereafterwards @Toshihiro Nakamura... there's no need to add any subclasses to the sealed class in another module... you'd be generating them all in ksp. I won't be adding any in my code. I'm talking about the generated
org.komapper.core.dsl.metamodel.EntityMetamodel
being the subclasses.
t

Toshihiro Nakamura

01/18/2023, 12:49 PM
However, how should the Komapper KSP processor determine the sealed interface name in that case?
d

dave08

01/18/2023, 12:50 PM
According to the
Meta
class name, maybe
Meta1EntityMetaModel
when
Meta1
is used?
Since it only makes sense to have a sealed interface per meta class... since another Meta class denotes another database. So any create or drops would be on ONE meta class's
allTables
t

Toshihiro Nakamura

01/18/2023, 12:57 PM
maybe
Meta1EntityMetaModel
when
Meta1
is used
How about the package name of the sealed interface? We want not to use
org.komapper
.
d

dave08

01/18/2023, 12:58 PM
You don't have to, all you need is a unique
Meta
object name... or to generate a unique name from it and use that in
allTables
.
It could even be OrgKomapperMetaEntityMetaModelBase...
It doesn't have to be exposed outside... but it might be nicer to have something that even users might use... so a short one would be more user friendly.
t

Toshihiro Nakamura

01/18/2023, 1:07 PM
There is still an issue with that approach. If you have two modules that use Komapper, the names of their sealed interfaces will conflict.
d

dave08

01/18/2023, 1:10 PM
How do you handle that for
Meta
objects? I don't think it makes sense that two separate modules should be able to contribute to the same Meta object's tables...?
t

Toshihiro Nakamura

01/18/2023, 1:45 PM
That is a possible use case. We use it in our Komapper integration testing. There is no problem using the same Meta object from two separate modules as long as the entity names do not conflict.
d

dave08

01/18/2023, 1:50 PM
How does one module use the other's entities? You'd need to make a cross dependency for each module to have a complete view of all the tables... I could understand that maybe a subset of tables in one database might be encapsulated into a module that is the only one to use those tables... in that case, which might not be so common, you could technically have an option to enable/disable the generation of
allTables
and the sealed interface altogether, but I don't see this as such a common case...?
Also, even in such a case, one could always create a new Meta object only for that module... so the option could be whether Meta could be used in a cross-module context... then the sealed interface would not be generated...
t

Toshihiro Nakamura

01/21/2023, 10:08 AM
I don’t think using sealed interface is a best idea. I tried to implement it using Service Provider. Let me know what you think. https://github.com/komapper/komapper/pull/857
4 Views