There seem to be little reactions on this issue.
I do think however that uncertaintity about this point perhaps could or
should stall the release 1.7.1 (which was stalled for too long btw), because
there might have arisen a backwards-compatibility issue here, and I'm not
sure how and if I should solve it. I would be in favour of suffering this
small issue, if a good rationalisation of behaviour is gained, but I might
stand alone here. Should I make it a VOTE? But then I'd like to see some
reactions beforehand?
I would then propose to make sure that (i hope your font is
non-proportional..):
field marked as NOT NULL field not marked
as NOT NULL
get<Type>Value getValue get<Type>Value
getValue
field unset -1,"" -1 -1,"" null
field set to null <previous value> <previous value> -1,"" null
field set 123,"123" 123 123,"123" 123
In this scheme I tried to indicated the several possibilities, for setting
and getting a field.
With the following meanings:
-1,"": The value of the field is null or unset, but is converted to an
'empty' value of the correct requested type. (For String "", for numbers -1
etc.)
<previous value>: If you unset a NOT NULL field, this should have given an error. I
think the previous value should remain.
123,"123": The value of the field, converted tot the right type. So, if the
type of the field was integer and the value was 123, and you asked
getLongValue then
it should give a Long with value 123 and if you asked
getStringValue then it should give the String "123". The excact
conversions are defined in org.mmbase.util.Casting.
-1: The empty value of the field 'as is'. So if the field is a
number then a Number is returned, if the field is a String, a String is
returned etc.
123: The value of the field 'as is'
I think this scheme is quite clear, and I suggest that everything that does
not currently work like this is to be considered a bug.
Furthermore, I propose that it should not matter whether a Node is commited or
not, freshly created, or not (This was not the case, and this was a bug
which I fixed).
If the field is besides marked as NOT NULL, also marked as UNIQUE (er,
perhaps that is called 'key'?), then leaving a field unset, or setting it to
NULL, should give an error.
There are then 2 other problems, and those are:
- What are the 'empty' presentations of NODE and XML fields?
-XML:
According to the javadoc getXMLValue could return 'null' (though does not
say that that should happen if unfilled). It gives back the Document
'[#document: null]'. That might be ok.
-NODE:
I propose that the 'empty' node must be some virtual node with number=-1.
I think it might return 'null' now, which would conflict with the
practical notion that e.g. get<Type>Value(..).toString() would never give
a NullPointerException.
Michiel
--
Michiel Meeuwissen
Mediacentrum 140 H'sum
+31 (0)35 6772979
nl_NL eo_XX en_US
mihxil'
[] ()
