message_id类型问题

[super1207]

在group_recall和friend_recall这两个通知事件中，message_id类型为int64，在撤回消息的api以及私聊/群聊事件中，message_id为int32。是否有误？

[ExerciseBook]

这个参数的由来是之前 酷Q 传参的时候参数签名为 OnGroupMessage(int subType, int sendTime, int64 fromGroup, int64 fromQQ, const char* fromAnonymous, const char* msg, void* font)

在 2017-11-15 前后改为了 OnGroupMessage(int subType, int msgId, int64 fromGroup, int64 fromQQ, const char* fromAnonymous, const char* msg, void* font) 并加入了 deleteMsg(int64 msgId)

因此当时是没有问题的，但是我个人认为现在我们可以把这个历史遗留问题给做掉。

[lz1998]

在takayama-lily/oicq中，message_id为string类型，可以考虑全部改为string

[ExerciseBook]

@lz1998 我觉得这个好。

[stdrc]

v12 可以考虑改成 string，或 uint64，另外 user_id 肯定得改成 string

[lz1998]

v12 可以考虑改成 string，或 uint64，另外 user_id 肯定得改成 string

但是改了以后会导致所有强类型的语言框架不兼容旧的代码，并且如果有人保存，数据库表结构也会发生变化

可以考虑增加字段message_id_str和user_id_str，不删除旧字段

[stdrc]

但是改了以后会导致所有强类型的语言框架不兼容旧的代码，并且如果有人保存，数据库表结构也会发生变化

其实 v12 不打算兼容 v11（（

[ExerciseBook]

v12 可以考虑改成 string，或 uint64，另外 user_id 肯定得改成 string

但是改了以后会导致所有强类型的语言框架不兼容旧的代码，并且如果有人保存，数据库表结构也会发生变化

可以考虑增加字段message_id_str和user_id_str，不删除旧字段

我也感觉会有这个问题。但是这个问题确实可以考虑要抛弃一下了。还是怕通用性不够。

[lz1998]

但是改了以后会导致所有强类型的语言框架不兼容旧的代码，并且如果有人保存，数据库表结构也会发生变化

其实 v12 不打算兼容 v11（（

反正都不兼容了，可以考虑把onPrivateMessage里面的onTempMessage分出来。。现在临时消息的处理比较复杂，回复也是需要通过缓存来进行记录