jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Waschkowski" <mwaschkow...@gmail.com>
Subject Re: 3.1.3.1 Removing Items
Date Tue, 24 Jul 2007 01:21:36 GMT
Hi Tako,

I wasn't comparing Hashmap to JCR, just stating an API that many people
would be familiar with and its use of nulls. Again, the most obvious example
is that variables in java can be set to null, and that has meaning. ie. its
null. the variable exists, and is set to a null value

"What would you do with a mandatory property for example?
Will you allow it to contain a null value? I think not because I would
expect a mandatory property to hold a "real" value."
Again, this is about the behavior mandated by the spec - setting a property
to null deletes the property as a side effect. With regards to a mandatory
property, the way I would expect JCR impl is to throw an exception if a node
was attempted to be saved and a mandatory property wasn't set. Certainly
null could be handled as well as no value.

"But if it can't contain null isn't it in fact exactly the same as not
having the property at all?
By definition you'd have to extend this idea to non-mandatory properties as
well because if we think the current situation (where setValue(null) is the
same as a remove()) is confusing think about a system where mandatory and
non-mandatory items have different semantics!"
It would be actually pretty darn straightforward - if a mandatory value
doesn't exist or is null when saving, then throw an exception.

Again, in Java having a variable set to null is a valid state, and it could
certainly be so in JCR. I'm surprised that its not, and would like to see it
changed. I don't want to beat a dead horse here, but as Alexandru has stated
'almost everywhere' (in the java space anyway), the semantic difference
between setValue() and remove() is respected in most java apis, probably
because the language itself works that way.

Regardless, what do you think - does having remove() and setValue(null) both
remove a property make sense to you? Or are you more concerned with the
ramifications of what other changes would have to be made to accommodate
changing the spec as the OP suggests?

Best,

Mark

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