views:

98

answers:

1

Hi,

I want to use an enum constant for a property value in jackrabbit. However the Node.setProperty() only accepts primitive types, String and Value as property value types.

I looked through the ValueFactory interface, but that also seems like it can't help me.


In other words I want to do this:

node.setProperty("name", Enum.Const);

and not this:

node.setProperty("name", Enum.Const.toString());

Thanks in advance.

+2  A: 

There is no standard way to do what you want. The JCR API simply does not allow storing arbitrary Object values. The only valid property types in JCR 1.0 are:

  • STRING
  • BINARY
  • LONG
  • DOUBLE
  • DATE
  • BOOLEAN
  • NAME
  • PATH
  • REFERENCE

All of these property types are valid in JCR 2.0, but there are several new ones:

  • WEAKREFERENCE
  • URI
  • DECIMAL

Plus, the javax.jcr.ValueFactory has no methods that create a Value from an arbitrary java.lang.Object.

There are three options:

  1. Use the STRING property type and convert your enum value to a String using 'toString()'; or
  2. Use the LONG property type and convert your enum value to an integral value using 'ordinal()' and casting as a long; or
  3. Use the BINARY property type and convert your enum value to a BINARY value

IMO, Option 1 makes the most sense. Option 2 may be better is some situations - for example it would allow using comparison operators on your property in JCR-SQL and JCR-SQL2. Option 3 would work, but it's not very practical at all.

Options 1 and 2 also can take advantage of node type constraints. As you may know, node type definitions include the property definitions and child node definitions allowed by that node type, and any of the property definitions can specify the allowed values using constraints. Constraints can, for example, limit the allowed property values via wildcard patterns or literal values (for STRING and PATH properties), value ranges (for LONG, DOUBLE, and DATE properties), length ranges (for BINARY), node type requirements (for REFERENCE and WEAKREFERENCE properties), literals (for NAME properties). Note that as a value is considered valid as long as it is allowed by any constraint.

Thus, for Option 1 or 2, the property definition describing an enumeration can use constraints to limit the allowed values. In the case of Option 1, the enumerations STRING literal values would limit the allowed values set on the property. Here's a simple example using the CND notation of JCR 2.0:

[ex:foo] mixin
- ex:bar (STRING) < 'VALUE1','VALUE2','VALUE3'

With Option 2, a range (or set of ranges) with the acceptable LONG values would work. Here's a simple example:

[ex:foo] mixin
- ex:bar (STRING) < [0,3)

Randall
Thanks for the exhaustive answer. I wanted to avoid comparing strings, since I have a node type which is an enum. Using property type String would allow values other than the ones defined in the enum to be used which would be a mistake. I already implemented it with option 1., but was kind of hoping there would be a better way :)
Simeon
Are you using a node type to define the property? If so, you could limit the values using constraints. For example, here's a mixin that defines a property 'ex:bar' of type STRING that only allows 3 values (sorry for the formatting):[ex:foo] mixin- ex:bar (STRING) < 'VALUE1','VALUE2','VALUE3'
Randall
Thanks ! This is great :) I still can't share the constants between the property definition and the code, but still its better than just strings. Could you add that to your answer for more visibility ?
Simeon