Migrating from hive to hive_ce? typeId 224 is a one-way door

hive_ce is the community continuation of Hive v2, and moving to it is mostly a dependency swap. Most of the time you can even roll back. But there are two typeId details that decide whether a rollback is possible, and whether the upgrade throws on day one.

Rolling back works, up to typeId 223

Original Hive caps custom typeIds at 223. hive_ce 2.10.0 raised the limit to 65439.

In our tests, data that hive_ce wrote with the same models and plain types read back correctly in hive 2.2.3. So if the migration goes wrong, you can go back.

Until you use a typeId above 223.

What happens above 223

Once you register an adapter above 223 and write with it, the original package can no longer read that box. We tested typeId 300 in hive 2.2.3 and got two different failures.

Registering the adapter:

HiveError: TypeId 300 not allowed. 

Opening the box without it:

HiveError: Cannot read, unknown typeId: 21. Did you forget to register an adapter? 

The 21 isn't your ID. It appears to be the marker hive_ce writes for an extended typeId. That's what we observed, not something the docs state.

Rule 1: keep a rollback window

Ship the plain migration first: same models, same typeIds, just the new package. Let it run in production for a release or two. Only then allow typeIds above 223.

That way, if something goes wrong in the first release, rolling back to hive is still an option.

Rule 2: check 200 and 201 before you upgrade

This one only affects Flutter apps. Since hive_ce_flutter 2.0.0, Hive.initFlutter() registers a ColorAdapter at typeId 200 and a TimeOfDayAdapter at typeId 201 for you. If one of your models already uses 200 or 201, your own registration throws:

There is already a TypeAdapter for typeId 200 

Check before you touch the pubspec:

grep -rnE "typeId *[:=] *20[01]\b" lib/ 

It catches both @HiveType(typeId: 200) annotations and hand-written adapters with final int typeId = 201;.

If you get a hit, don't renumber your model. Changing a typeId orphans every record already stored under it. Move the Flutter adapters instead: since hive_ce_flutter 2.3.0 their IDs are configurable as optional parameters of initFlutter (colorAdapterTypeId, default 200, and timeOfDayAdapterTypeId, default 201). Pick two IDs no model of yours uses.

Bonus: find the hidden copies of hive

Your pubspec can be clean while your dependency tree is not. For example, hydrated_bloc 9.1.5 and older depend on hive, and a forgotten hive_flutter line brings it back.

flutter pub deps | grep -E "\bhive(_flutter|_generator)? [0-9]" 

Anything it prints is the original package, not the CE one.

Further reading: the full migration guide, tested on real Hive 2 box files, is on our blog: Migrating from Hive to hive_ce.

Have you moved to hive_ce yet, or are you still on the original package?