[
https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234298#comment-13234298
]
Felix Meschberger commented on OAK-33:
--------------------------------------
> OakValue, Scalar, Atom: all are fine for me
I happen to like Scalar. Atom sounds wrong and OakValue is too close to JCR
"Value"
> The value abstraction should be expressed as an interface in .oak.api
I agree this to go into the API -- provided it is used outside of Oak Core (for
example in the JCR implementation
layer).
Whether it be an interface or a concrete class, it depends on the use. I am
fine for value (in the sense of Integer, Long, etc. value classes) classes to
be exposed by the API. These are immutable and possibly even final (or at least
not intended to be extended by client code). I see no issue with exposing them
in an API. If there might be a open variety of implementations, maybe even
custom implementations for special use cases, having an interface (in addition)
might make sense.
> 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
