现象
更新money字段的值sql，却报too long for column "type"，其实更新语句不涉及type字段，但问题在这里。
有遇到类似问题的，接下来对号入座。
出现这这个问题，有以下几种情形：
1. java定义type字段是int类型
2. db中这个字段是enum类型
3. 插入和查询时这个字段是没有问题的
4. 更新这个字段没有问题
5. 更新别的字段的同时没有更新这个字段，就出问题了，如果更新过这个字段问题解决，下次重启，问题复现
6. 用的h2数据库
原因
翻了下出问题异常堆栈的时候，在一个方法上看到这个注释：
这里可以看出，即使更新一个字段也会处理所有列。。。虽然更新的时候没有这个字段，依然会处理下。
抛异常的地方在这里：value是int类型，value的precision的值是10，参数precision的值是7（应该是按‘complex'的长度计算的，即enum的最大字段的长度）。这里判断value的precision过大，不合法，就异常了。
而type列的值是0或1，一个整数类型。在后面有个精度计算判断的时候，int的为10，而这个enum类型的type列的精度为7,不合法了。就抛这个异常了。
出现type列为Int类型的原因看下图，在Page.read(buff, pos, map)方法内，后面有很多操作，就不一一截图了。我花了大晚上时间翻这块代码，搞清楚它这个反序列化过程（先key,然后是values，在处理values时把一行的每一个列依次反序列化，buff里保存了很多信息比如类型，值什么的，有它自己的编解码方式）。在初始化的时候计算的这个type column的信息就是enum，但是这里反序列化出来的类型信息，如果是enum或int都按int处理，返回的就是值的角标。
这是h2自己加载数据的时候，反序列化的7个字段中，type直接就是ValueInt，尴尬了。
因此，我发现了个很尴尬的问题，它自己取的列属性是enum，反序列出来的值类型是int。这里是它引擎自己的事，和框架无关。
解决办法
没有找资料看别人怎么弄，不过看源代码这里找到了出现原因和问题所在，我先考虑从代码层面尝试解决，按规范定义java bean，把这个字段定义为enum类型映射，明知道其实和这个关系不大（即使直接执行原生sql也是这问题），还想试下。
果然，重启之后，结果还是报这个错。
然后，想着把db中enum的字段字义改长点，超过10位，如：
alter table T_VIP_USERS alter column type set data type enum('complex_card', 'haircut_card') ;
测试更新money却报type字段 too long这个问题已经没有了，，，然后测试了下代码的插入操作也没有问题了。只是觉得这个问题解决的很尴尬，不像正道。。。