[
https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234805#comment-13234805
]
Jukka Zitting commented on OAK-33:
----------------------------------
In revision 1303477 I dropped the {{getDecimal()}} method from the {{Scalar}}
interface until we decide which range of value types to support at this level
of abstraction. I think we have two main alternatives:
* Support only those types that can be directly expressed on the MicroKernel
level, essentially just JSON types and binaries. Note that _numbers_ are a bit
vaguely defined in JSON (and JavaScript in general), so {{getDecimal()}} might
actually be better than {{getLong()}} and {{getDouble()}}. Ultimately we need
to figure out how the MicroKernel expects to store numbers and use that as the
basis of our abstraction.
* Support the full set of JCR types. Things like names, paths, and references
would still be opaque at this level (we wouldn't have namespace mappings or
dereferencing methods), but such values would still be explicitly typed.
My intuition is to prefer the first option, but I don't have a stronger opinion
on this.
> 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
