Isn't the `typeId` range too limiting?

[obeobe]

According to https://docs.hivedb.dev/#/custom-objects/type_adapters , the max typeId of Type Adapters is 223. If I understand correctly, this limits the number of different entity types that can be used in an application to 223. Even if this limit is sensible for number of "concurrent" entity types, as the application evolves some old types may be deprecated and replaced by new ones. If I want to allow migrating from old versions, I can't re-use older typeIds.

So, is it correct that when I get to typeId of 223, my only option for adding a new entity type is to no longer support migrating data from old versions that might still use a typeId of 0?

The same question also applies to the field numbers (max is 255, according to https://docs.hivedb.dev/#/custom-objects/generate_adapter ), although in this case I suppose there can be workarounds, like creating a new entity class (with a new typeId) and copying the data over to a new box.

Did I misunderstand anything? if not, are there plans to increase these limits?

Thanks!

[bit-garden]

Try deleting all of that type from the hive, then when there's none left of it, you can use the id for something else. Or read from one hive box to a new one. Only the used types would come over. They technically don't have to be sequential.

223 types is pretty liberal I think and if you run up on this, you may be either hitting design issues or needing to use another db solution.

[obeobe]

I don't think it's a good practice to re-use ids, and don't see the sense in adding complexity by migrating hive boxes.

Getting to 223 is not that hard if you support an application over a long period of time and don't want to reuse past identifiers. Especially if it's an enterprise app.

Why would you want to pose such a limit in the first place?

[heafox]

+1