jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu ☀" <the.mindstorm.mailingl...@gmail.com>
Subject Re: Removing Items
Date Fri, 20 Jul 2007 08:09:47 GMT
On 7/20/07, Julian Reschke <julian.reschke@gmx.de> 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? :-)

.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

View raw message