jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peeter Piegaze <peeter.pieg...@gmail.com>
Subject Re: Question on the meaning of "the property does not yet exist".
Date Sat, 12 Mar 2005 00:00:50 GMT
Hi Doug,

Well, in a sense both views are correct in that both case 1 and case 2
comply with the spec. But view 2 is "more correct" because it is more
general: whether the implementation pre-allocates space for defined
properties and then keeps track of their set/unset (or exist/not
exist) status is indeed an implementation-level issue.

The phrase "the property does not exist" is not a statement about
whether space for the property has or has not been allocated by the
implementation. It is a statement about whether the property exists at
the JCR-level, that is, whether a getProperty will work (assuming
access rights are sufficient, etc.) or not.

Hope this helps. If I have misunderstood your question please let me know.


On Fri, 11 Mar 2005 17:50:03 -0500, McComsey, Doug <Doug.Mccomsey@ca.com> wrote:
> 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>

View raw message