jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-33) Values in oak-core
Date Wed, 21 Mar 2012 13:23:39 GMT

    [ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234342#comment-13234342
] 

Thomas Mueller commented on OAK-33:
-----------------------------------

Jukka mentioned that OakValue is also a problem because we might want to change the project
name at some point.

Scalar sounds good as well. First I thought it's not a good match but after reading the Wikipedia
article I like it.

> a single internal value representation which also works for the jcr bindings

This sounds interesting: it would avoid converting values (copying data). Also, we would only
need one "value cache". It would save memory and speed up things. Unfortunately, it couldn't
be an interface then ("ValueImpl extends Scalar" wouldn't work if Scalar is only an interface).

Another question is multi-value properties. I kind of don't like using Scalar[] and ValueImpl[]
everywhere just because a property *could* be a multi-value property. I'm not sure how to
be solve this. JsonValue has isArray(), which sounds interesting.
                
> 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

        

Mime
View raw message