[
https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234346#comment-13234346
]
Michael Dürig commented on OAK-33:
----------------------------------
> Another question is multi-value properties. I kind of don't like using
> Scalar[] and ValueImpl[] everywhere just because
> a property could be a multi-value property. I'm not sure how to be solve
> this. JsonValue has isArray(), which sounds
> interesting.
Ack wrt. the issue with multi valued properties. If we go down the same route I
chose for JsonValue (i.e. algebraic data types) we shouldn't use Scalar and
Vector for the concrete types and come up with a better name for the abstract
value type. I.e.:
{code}
abstract class Value {
class Scalar extends Value{}
class Vector extends Value{}
}
{code}
> Values in oak-core
> ------------------
>
> Key: OAK-33
> URL: https://issues.apache.org/jira/browse/OAK-33
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Thomas Mueller
>
> There is no JCR API in oak-core, but we still need to deal with values and
> data types. We have multiple options, I can think of:
> (A) String everywhere, as in oak-mk
> (B) Use javax.jcr.Value
> (C) An immutable "Value" class (but doesn't need to be called "Value")
> There are multiple problems with (A), for example compile time safety, and I
> fear the code would get unnecessarily complex, not as efficient as it could
> get (specially when dealing with numbers), memory usage would be higher.
> I think we said (B) isn't an option because we don't want to use the JCR API
> in oak-core (see also OAK-16).
> As for (C), I have a first prototype, mainly because I needed it to be able
> to migrate the query feature to oak-core. The prototype is in
> org.apache.jackrabbit.oak.query.ValueFactory
> org.apache.jackrabbit.oak.query.Value
> org.apache.jackrabbit.oak.query.PropertyType
> It's very similar to javax.jcr (even the property types are the same), but
> the values are immutable. They currently implement Comparable<Value>, but
> that's also open for discussion. One sub-problem is binaries: should they
> contain a reference to the MicroKernel instance, or some other "storage
> backend" (possibly a temp file backend)?
> Concrete suggestions (and patches) are welcome.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
