[
https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234287#comment-13234287
]
Thomas Mueller commented on OAK-33:
-----------------------------------
> We should use some other name
OakValue, Scalar, Atom: all are fine for me. Although "CoreValue" would be more
funny. Anyway "Value" is troublesome because we would also need to use it in
oak-jcr. My first choice would be "OakValue", followed by "Atom", then "Val",
and then "Scalar".
> The value abstraction should be expressed as an interface in .oak.api
Personally, I would use a concrete "Value" class. But I know concrete classes
as part of an API are problematic. Maybe I just think too much about
performance implications and simplicity (I would expect the "Value" class is
really simple and small).
> Binary values should be a part of this value abstraction
Yes, so the "Value" should have an getInputStream(), and length(). But
getInputStream() should always return a new stream (unlike javax.jcr.Value).
And length() would possibly ask the MK implementation for the length (but just
once).
> 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
