[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239409#comment-13239409 ]
Thomas Mueller commented on OAK-33: ----------------------------------- This didn't turn out like I expected. Currently we have: * oak-mk / org.apache.jackrabbit.mk.model.Scalar: interface for a JSON value, _without_ JCR property type info (only JSON type info) (boolean, long, double, binary, string, null) * oak-core / org.apache.jackrabbit.oak.kernel.ScalarImpl: implements the Scalar interface in oak-mk * oak-core / org.apache.jackrabbit.oak.query.ScalarImpl: _with_ JCR property type info To avoid confusion about naming, I will rename query.ScalarImpl to CoreValue for now. This is a temporary name. With might want to add an interface for that later on. Unlike the current Scalar interface (which represents a JSON value), the CoreValue represents JCR value, including JCR property type info. > 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