[
https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234273#comment-13234273
]
Jukka Zitting commented on OAK-33:
----------------------------------
+1 for (C)
Some comments:
* We should use some other name than Value (and ValueFactory) to avoid
confusion with JCR. Some ideas: OakValue, Scalar, Atom
* The value abstraction should be expressed as an interface in .oak.api since
we'll need to use it when passing data to and from clients.
* Binary values should be a part of this value abstraction, as otherwise we
need to come up with another, parallel solution for binaries.
* I'd back binary values with an MK blob reference. There should be no other
storage mechanism in oak-core.
> 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
