TypeHandler support the recursive search.

[liyuj]

In some scenarios, need to define a generic typehandler for some custom types, so typehandler can be search in a recursive manner,is very valuable.

[harawata]

This is basically a duplicate of #604 .
There seems to be a need for this feature, so I will look into it.
We need to be careful as this method affects performance.

[liyuj]

Interface support needs to be carefully considered, because this will lead to the complexity of the problem, but the class to look up should not be a problem. Generally speaking, custom types will not be very complex, the inheritance hierarchy will not be a lot, so the impact on performance is very small, if this leads to performance problems, it is also the developer's design led to. 在 2016/12/2 17:31, Iwao AVE! 写道:

…

This is basically a duplicate of #604 <#604> . There seems to be a need for this feature, so I will look into it. We need to be careful as this method affects performance. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#859 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AI0QgmzA04EQNF3WEOrYQOsfrqgAOx8bks5rD-VbgaJpZM4LCK6E>.

[harawata]

Is it a bad idea to add a new entry to TYPE_HANDLER_MAP when matching entry for a superclass is found?

  if (jdbcHandlerMap == null && type instanceof Class){
    Class c = ((Class)type).getSuperclass();
    while(c != null && c != Object.class){
      jdbcHandlerMap = TYPE_HANDLER_MAP.get(c);
      if (jdbcHandlerMap != null) {
+        TYPE_HANDLER_MAP.put(type, jdbcHandlerMap);
        break;
      } else {
        c = c.getSuperclass();
      }
    }
  }

Then the superclass-scanning is performed only once for a subclass and it would save a decent amount of time when dealing with a large number of rows.

[liyuj]

This is indeed an optimization. But in our scenario, we defined a number of enum, we want to define a TypeHandler for Enum.class, as if to amend the above method, causes the TYPE_HANDLER_MAP to take up a lot of memory. On 12/6/2016 13:04， Iwao AVE!<notifications@github.com>wrote： Is it a bad idea to add a new entry to TYPE_HANDLER_MAP when matching entry for a superclass is found? if (jdbcHandlerMap == null && type instanceof Class){ Class c = ((Class)type).getSuperclass(); while(c != null && c != Object.class){ jdbcHandlerMap = TYPE_HANDLER_MAP.get(c); if (jdbcHandlerMap != null) { + TYPE_HANDLER_MAP.put(type, jdbcHandlerMap); break; } else { c = c.getSuperclass(); } } } Then the superclass-scanning is performed only once for a subclass and it would save a decent amount of time when dealing with a large number of rows. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[harawata]

Assuming that the current version of MyBatis works fine with your solution, memory usage should not be a problem.
Because the value (jdbcHandlerMap) of a new entry is just a reference, memory usage will actually be smaller than the current version with the same type handler entries, at least.

If it still concerns you, give me some time and I will do some profiling.

[liyuj]

If possible, as soon as possible to release the 3.4.2 version, it is very good. We wrote a lot of code to deal with this problem. 在 2016/12/6 17:22, Iwao AVE! 写道:

…

Assuming that the current version of MyBatis works fine with your solution, memory usage should not be a problem. Because the value (|jdbcHandlerMap|) of a new entry is just a reference, the memory usage will actually be smaller than the current version with the same type handler entries, at least. If it still concerns you, give me some time and I will do some profiling. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#859 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AI0QggBk4aYRTxNH0nT8Bvk0MYfwk45Xks5rFSlRgaJpZM4LCK6E>.