Le mar. 17 mai 2022 à 23:54, David Blevins <[email protected]> a écrit :
> > On May 16, 2022, at 11:29 PM, Romain Manni-Bucau <[email protected]> > wrote: > > > > Strictly speaking - not saying we can't change it - it was the intent. > > Rational (keep in mind originally point was that converter (string) were > > always sufficient but jsonb made it complicated) was that binding null - > > JsonValue.NULL, too big data, java out of bound value, .... - is ok but > > serializing something in an object as null was a bug (lost of data). > > Yeah, I struggled with that one and couldn't quite reach a confident > opinion as I can see it both ways. > > The thought that leads me to think it is not a bug is that there are no > scenarios where we see a null in a json document and pass that in and say > 'convert/adapt this" As well if you wanted null to be written, you could > set the pre-converted value to be null. > > Then I think through scenarios where it might be > hard/impractical/impossible to actually go through and null out properties > in the object tree so null shows up in the json. Any final field would > pose a challenge as would poking out null values from a large array or > immutable collection. Even if the thing wasn't final, I'd probably still > be mad I had to "pay twice" by walking the object tree, evaluate all my > convertable/adaptable fields before serialization only to have to evaluate > them all again during serialization. > > > > > Now where it gets complicated: > > > > 1. Spec - jsonb - is ambiguous even if yasson supports null both ways > > I didn't check yasson. > > > 2. We cant break users by default (means a JsonbConfig toggle, default > > being backward compat I'd say) if we want to support it > > > > Hope it helps a bit > > Sort of. Maybe the best approach then is to add that flag and then > improve the NullPointerException so it says "set this property if you want > to return null ... blah blah blah" Then users would see the solution in > their exception. > Well, if we do I fear we have to make it work and skip exceptions. I hardly see us breaking which means catching NPE around adapters and hoping we can ignore it...which is inconsistent with your work on exceptions :s. > Another thought which just occurred to me is what if we had an annotation > that could be put on the converter/adapter? If we get a null, we check for > the annotation. If we find it we allow the null, if not we default to > throwing an exception. > Sounds not bad to me - just check the annot when creating the mapping model and store it, not at runtime when "we get a null" please. The "if not" can stay what we have I think, ie ignore which is consistent with our and jsonb defaults to ignore null by default. > Thinking out loud. > > > -David > >
