It might also be nice to generate a list or set of all of the contents of each Meta object in the Me...

# komapper

[dave08]

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]

We had the same discussion here:
https://github.com/komapper/komapper/issues/681

[dave08]

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]

@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]

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]

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

[dave08]

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

[dave08]

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]

maybe Meta1EntityMetaModel when Meta1 is used

How about the package name of the sealed interface? We want not to use org.komapper.

[dave08]

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]

It could even be OrgKomapperMetaEntityMetaModelBase...

[dave08]

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]

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]

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]

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]

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]

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]

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