search

TeamWizardry / LibrarianLib

A library for the TeamWizardry mods
GNU Lesser General Public License v3.0
26 stars 21 forks source link

Decide how to represent null in NBT #136

Closed thecodewarrior closed 3 years ago

thecodewarrior commented 4 years ago

As it is right now, null values are represented by missing keys. This could lead to issues when trying to load old data since it'll set all the newly added fields to null. How to safely represent null without bloating the NBT data will be tricky, so this should be carefully considered before LibLib 5 is officially released.

Bluexin commented 4 years ago

I think key: null is the safest. Especially for data migration. I don't think it would be a bloat.

thecodewarrior commented 4 years ago

The problem is there's no null tag, so making a value that's unambiguously null is impossible, so trying to figure out something reasonably unambiguous while not being too bloated. One potential solution would be key: { null: true }, which would break fields named null, and potentially maps containing only a "null" key.

yrsegal commented 4 years ago

It was decided to be how it is because there is no sensible representation of null besides nonpresence.

thecodewarrior commented 4 years ago

That seems reasonable, but we'd need to work out a way to properly handle data migration. Whatever we decide on would probably be implemented on Prism's side as part of the ObjectAnalyzer.

thecodewarrior commented 3 years ago

We're going with missing keys. Data migration will be done on the LibLib's side by the SimpleSerializer