jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tako Schotanus" <quinte...@gmail.com>
Subject Re: 3.1.3.1 Removing Items
Date Fri, 20 Jul 2007 10:55:18 GMT
On 7/20/07, Alexandru Popescu ☀ <the.mindstorm.mailinglist@gmail.com> wrote:
>
> On 7/20/07, Tako Schotanus <quintesse@gmail.com> wrote:
> > On 7/20/07, Alexandru Popescu ☀ <the.mindstorm.mailinglist@gmail.com>
> wrote:
> > >
> > >
> > > On the other side, I still think that there are cases where NULL and
> > > non-existant may mean different things.
> > >
> > > Confusing isn't it? :-)
> >
> >
> > To me there is no confusion, null in either a programming language or a
> DBMS
> > means the absence of value.
> >
>
> Well, I think this is still opened to debate ;-). A collection
> containing 2 values and 3 nulls is the same with a collection having
> only the 2 values? And I do think we can go very far with this
> discussion :-), so maybe we should agree that this is just a debatable
> topic.


It is not the same thing, true, but it is meaningless, what does having 3
null values in a collection _mean_? Even if it is possible to do so (many
collection implementations don't even allow you to add nulls) you could
probably exchange the null value for an empty object, which suggests that
they are interchangeable. Again, the fact that you would like to differ
between the two doesn't necessarily mean it's wise to do so.

> That YOU add a specific meaning to the absence of that value is okay, but
> it
> > is generally considered bad practice because it is not obvious just by
> > looking at the data what your intentions are. In those cases it is
> suggested
> > that you explicitly model the different states that you want to
> recognize.
> >
>
> You are totally right about this. But you should probably agree that:
> property.setValue(null) is not the same with property.remove() (it is
> only in the JCR spec).


Well, actually, no I don't agree. You have to think about what does it
_mean_, what does it mean to have a property that has no value?

I can see 2 options:

- either the mere existence of the property is enough, compare this with the
HTML <option ... selected> where it's enough for the property to exist, it
does not need a value. But in this case it actually doesn't matter what
value you choose for the property, it could be anything so you don't need
support for null (I think that many HTML DOM implementations just use the
name of the property as its value, eg selected="selected").

- or the property needs a value but is optional. So you can leave it out if
you want, or you could give it a value, you can even give it an empty value
if permitted by its data type, so you've already covered all reasonable
use-cases.

The fact that NULL exists in a database is because there is no other way to
determine the absence of data otherwise, but in in the hierarchical model
you can just leave out the data and that's it.

I just don't see any use-cases, except for contrived ones, that would merit
adding support for null values (at this moment anyway).



> Many arguments in this thread are based on the XML representation. And
> I don't think this is quite correct: the fact that hierarchical data
> can be expressed with XML is one thing (and the fact that the JCR spec
> offers this feature), but thinking that hierarchical storage is
> equivalent to XML storage is imo a mistake. JCR supports hierarchical
> storage, but is not an XML based storage.


I agree, but it's easy for representing  example data because everybody
knows it.
XML is also limited in the things it can represent of course, but I think
that in this particular case it's okay to use XML as an example because even
with XML I don't see a need to distinguish between:

<!-- element without property -->
<data />

<!-- element with null property -->
<data property="&null;" />

for the reasons I gave above.

Cheers,
 -Tako
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message