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: 3.1.3.1 Removing Items
Date Fri, 20 Jul 2007 09:04:49 GMT
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.

> 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).

> So instead of doing the following for example:
>
> <!-- requested and got the information -->
> <data>
>    <someInformation>The contents...</someInformation>
>    .
>    .
> </data>
>
> <!-- requested and received empty information -->
> <data>
>    <someInformation />
>    .
>    .
> </data>
>
> <!-- requested but didn't get the information -->
> <data>
>    <someInformation isNull="true" />
>    .
>    .
> </data>
>
> <!-- haven't requested the information yet -->
> <data>
>    .
>    .
> </data>
>
>
> It's much better to explicitly state your intentions:
>
>
> <!-- requested and got the information -->
> <data>
>    <someInformation requested="true" received="true">The
> contents...</someInformation>
>    .
>    .
> </data>
>
> <!-- requested and received empty information -->
> <data>
>    <someInformation requested="true" received="true" />
>    .
>    .
> </data>
>
> <!-- requested but didn't get the information -->
> <data>
>    <someInformation requested="true" received="false" />
>    .
>    .
> </data>
>
> <!-- haven't requested the information yet -->
> <data>
>    <someInformation requested="false" received="false" />
>    .
>    .
> </data>
>
>
> (although I can understand that in the last case you'd rather just leave out
> the element)
>

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.

bests,
./alex
--
.w( the_mindstorm )p.

> Cheers,
>  -Tako
>
Mime
View raw message