On 7/20/07, Julian Reschke <[EMAIL PROTECTED]> wrote:
Alexandru Popescu ? wrote:
> I don't think I agree on this. As you said: null and empty strings are
> distinct values. Another distinct case is: innexistance, which is not
Yes.
> synonymous with null or empty. Atm you cannot store a null value
Well, in the JCR property model "null" and non-existance are the same.
As far as I can tell, the same applies to WebDAV properties, RDF and the
XPath data model.
I think it is a *feature* that these data models are compatible.
BTW: what would be a use case for the ability to differentiate between
"null" and "not there"?
Well, I think this is a theoretical discussion, and I may not be
holding the explanation for it. Imo null can be seen as a predefined
value (as is True/False, +/-Infinite) and it can be seen as different
to "non-existant".
Getting back to a real use case, I will try to present one: lazy
registration pattern (gradually data gathering): for this scenario a
non-existant value may mean that the data was never asked for, while a
NULL may mean that the data was asked for and answered with nothing.
For supporting this scenario, right now you need to use a app specific
value to mark the case.
I will finish by saying that I am not 100% sure this is an issue or a
feature. People that are seeing it as an issue are most probably
people coming from a RDBMS background where NULL is a predefined value
-- but mainly because not-existance cannot be expressed otherwise. On
the other side, I still think that there are cases where NULL and
non-existant may mean different things.
Confusing isn't it? :-)
bests,
./alex
--
.w( the_mindstorm )p.
> inside JCR -- and for solving this one must usually create a null-like
> value.
>
> The OP is suggesting that this is a spec issue and storing null values
> should be allowed. But doing so results in API behavioral changes,
> because currently property.setValue(null) is equivalent to remove.
Correct.
Best regards, Julian
