jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "McComsey, Doug" <Doug.Mccom...@ca.com>
Subject Question on the meaning of "the property does not yet exist".
Date Fri, 11 Mar 2005 22:50:03 GMT
A coworker and I have two different views of what  the term "the
property does not yet exist" means in the API for
Node.setProperty(Value). I would like to present the two views and
solicit feedback on them from David Nuescheler or anyone else who might
have an opinion.

 

The API for Node.setProperty(Value) states: (emphasis mine)

"Sets the specified (single value) property of this node to the
specified value. If the property does not yet exist, it is created. The
property type of the property will be that specified by the node type of
this node.

 

If the property type of the supplied Value object is different from that
required, then a best-effort conversion is attempted. If the conversion
fails, a ValueFormatException is thrown. If another error occurs, a
RepositoryException is thrown. 

 

If the node type of this node does not indicate a specific property
type, then the property type of the supplied Value object is used and if
the property already exists it assumes both the new value and new
property type.

..."

 

View 1

The phrase "the property does not exist" means just what it says.  If a
node has 2 properties then at the end of the setProperty operation the
node will have 3 properties, assuming that we are setting a brand new
property.  Now, in the context of jcr I am also bound by type definition
rules, both at the node and at the property level.  Assuming that no
constraint rules are broken at the jcr level a node will always have a
new property attached to it.  

 

View 2

The term "the property does not exist" means that for a specific Node no
value has been set for that property. It is up to the implementation to
determine how to keep track of the "set" / "unset" state of a property.


 

The behavior is:

*	Calling setProperty on an undefined property throws a
ConstraintViolationException and nothing is added.
*	Calling setProperty on a defined property that is "unset" stores
the value and changes the state to "set". However, if the supplied value
is null, the value is not stored and the state is changed to "unset".
*	Calling removeProperty on a defined property changes the state
to "unset".    
*	Calling getProperty on a property that is "unset" results in a
PathNotFoundException.

 

Properties defined as Protected or those with default values in the
property definition are always in the "set" state. Removing a value from
a property with a default value simply restores the default.

 

NOTE: The limitations of our implementation forbid the use of wildcards,
so all properties will have property definitions.

 

 

Which view is closer to the truth, or is there another view?

 

Regards,

Doug

 

Doug McComsey

Computer Associates

Senior Software Engineer

tel: 214-473-1331, or 11331

fax: 214-473-1168

doug.mccomsey@ca.com <mailto:doug.mccomsey@ca.com> 

 

 


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