3

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.

Simeon
  • 7,582
  • 15
  • 64
  • 101

1 Answers1

9

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 Hauch
  • 7,069
  • 31
  • 28
  • 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 Sep 28 '10 at 15:12
  • 1
    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 Hauch Sep 28 '10 at 15:43
  • 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 Sep 30 '10 at 07:34
  • _`Use the LONG property type and convert your enum value to an integral value using 'ordinal()'`_ this sounds like a pretty bad idea because it assumes the order of values in an enum does not change. Ordinals shouldn't be used to identify enum values. – toniedzwiedz Nov 19 '14 at 12:03
  • Using a LONG property and the enum's ordinal is definitely not ideal, but it is possible if you control the enum definition and thus the order. Again, I'd try not to do it but it's possible. – Randall Hauch Nov 25 '14 at 14:53