On 7/20/07, Alexandru Popescu ☀ <[EMAIL PROTECTED]> wrote:
On 7/20/07, Tako Schotanus <[EMAIL PROTECTED]> wrote: > On 7/20/07, Alexandru Popescu ☀ <[EMAIL PROTECTED]> 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
