It might also be nice to generate a list or set of all of th

Question

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

Toshihiro Nakamura · Answer

We had the same discussion here <https github com komapper komapper issues 681>

dave08 · Answer

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>

dave08 · Answer

< 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

dave08 · Answer

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

Toshihiro Nakamura · Answer

However how should the Komapper KSP processor determine the sealed interface name in that case

dave08 · Answer

According to the `Meta` class name maybe `Meta1EntityMetaModel` when `Meta1` is used

dave08 · Answer

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`

Toshihiro Nakamura · Answer

gt maybe `Meta1EntityMetaModel` when `Meta1` is used How about the package name of the sealed interface We want not to use `org komapper`

dave08 · Answer

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`

dave08 · Answer

It could even be OrgKomapperMetaEntityMetaModelBase

dave08 · Answer

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

Toshihiro Nakamura · Answer

There is still an issue with that approach If you have two modules that use Komapper the names of their sealed interfaces will conflict

dave08 · Answer

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

Toshihiro Nakamura · Answer

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

dave08 · Answer

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

dave08 · Answer

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

Toshihiro Nakamura · Answer

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>