It is not entirely clear to me what should happen when field values are
unset or set to null. Furthermore, the extra complication of the 'notnull'
setting in the builder xml's occurs.
Using the new storage I spotted the bug #6481, which had to do with unset
fields. The problem was that storage considered those fields notnull and
changed the value, making dove think that the value changed, which caused an
exception in editwizards.
I also though that #6493 was a bug but in retrospect I'm not entirely
certain anymore.
What comes closest to reality for nullable fields was the following
situation:
If the value of a field (let's call it 'a') was not-set, then
getValue('a') returns null;
getStringValue('a') returns "";
getIntValue('a') return -1; etc..
The only exception was perhaps if the field 'a' was of type byte[] in which
case getValue('a') returned byte[0], which inconsisentcy I might have fixed
by my fix for #6493, but I am now not sure if I should have (but I do think
it strange that byte-array fields should be any different)
I'm not sure what should happen if you do:
setValue('a', null);
I think that for nullable fields this should simply return to the 'unset'
situation (where NULL can be in the database).
If the field is marked 'notnull' in the builder xml's things are going to be
different obviously.
getValue('a') still can return null. I think this is errorneous, because in
the database it cannot be like that.
getValue('a') should IMHO never return 'null' for existing not-nullable
fields, but I'm pretty sure that it does now (perhaps if the node still comes from
the node-cache).
I think all-in-all the situation is a bit chaotic and I'd like a simple
clear concept leading to the following rules:
nullable fields:
- getValue() returns null if value set to null or unset.
- get<Type>Value() never returns null, but the 'empty' value of the correct
type ("", -1, byte[0]).
- setValue() can accept 'null' as value, which 'unsets' the field.
not-nullable fields:
- getValue() never returns null, even if the field is still unset, you would
retrieve the value which would be stored by storage (which _must_
unnullify the value, because NULL simply cannot be stored)
- get<Type>Value() also never returns null
- setValue() would throw exception if you set 'null' in it, or at least
warning would be logged by storage, because 'null' cannot be stored.
Michiel
--
Michiel Meeuwissen
Mediacentrum 140 H'sum
+31 (0)35 6772979
nl_NL eo_XX en_US
mihxil'
[] ()
