We don't really want to export type handlers unless absolutely necessary.

Why mroonga needs them? It seems that it doesn't, and the dependency is created because type_handler_enum, for example, is used in field.h in a couple of methods. But these methods are virtual, they cannot be inlined and there's no reason to have them in field.h. That is, it looks like the cleaner fix would be to move these methods to field.cc and remove this unnecessary dependency.

Also, how did you manage to compile mroonga on Windows? It disables itself unconditionally:

  set(MRN_GROONGA_BUNDLED TRUE)

  if(MSVC)

    # Bundled Mroonga does not support MSVC yet

    return()

  endif()

Thank you for your comments.

> We don't really want to export type handlers unless absolutely necessary.

> Why mroonga needs them? It seems that it doesn't, and the dependency is created
> because type_handler_enum, for example, is used in field.h in a couple of methods.
> But these methods are virtual, they cannot be inlined and there's no reason to have
> them in field.h. That is, it looks like the cleaner fix would be to move these
> methods to field.cc and remove this unnecessary dependency.

That is certainly true. Mroonga doesn't use them.
So, I agree that these methods move to "field.cc".

> Also, how did you manage to compile mroonga on Windows? It disables itself
> unconditionally:

We have used https://github.com/mroonga/mroonga/blob/master/CMakeLists.txt and GitHub Actions( https://github.com/mroonga/mroonga/blob/master/.github/workflows/windows.yml#L139-L148 ) of Mroonga project for compiling Mroonga.

Unrelated to the bug report, but is there a newer mroonga that you would want us to include in MariaDB?
If yes — please create a pull request and we'd be happy to include it. Now just this one time, I mean, but also in the future whenever you want us to move to a newer mroonga.

Thank you for your suggestion.
There is a newer Mroonga that we want to include in MariaDB.

We will make the pull request.
However, this work takes time.
Because the newer Mroonga has many modifications.

If we finished update to the Mroonga that was included in MariaDB, we hope to update regularly(For example, we send pull request for updating every month.).

However, we difficult maintenance the Mroonga that is included in all active versions of MariaDB.
So, we hope to update only the latest MariaDB version.

Absolutely. In whatever version you want and whenever you want.

Once a month is even too often, we release quarterly, so one pull request every three months is sufficient. You can do more often, but we won't release more often, so you'd be just wasting time on preparing these pull requests.

Thank you.

I understand it. We will send one pull request about every three months.
We will send the pull request for updating to the Mroonga that is included in MariaDB sometime soon.

What about all other type handlers? For example, type_handler_bit? It's also used in field.h — why is it not a problem for you?

I just tried to move type_handler_enum to field.cc and saw that many other type handlers are used in a similar what. Thus I'm hesitant to fix this issue blindly without any way to test it.

So, let's wait until you provide a newer mroonga where I'll be able to see these failures and then I fix them. Or, if you want it sooner, you can provide a patch that moves relevant virtual methods from field.h to field.cc.

Thank you for your comment and fixing.

Currently, other type handlers are not a problem.
I also think that it is strange. However, I don't know why for now.

We are not much in a hurry about this problem.
The solution to this problem is all right after the new Mroonga releases.