Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Date: Wed, 21 Mar 2012 11:59:39 +0000 (UTC)
From: =?utf-8?Q?Michael_D=C3=BCrig_=28Commented=29_=28JIRA=29?=
 <jira@apache.org>
To: oak-dev@jackrabbit.apache.org
Message-ID: 
 <1015288409.41373.1332331179930.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <879830662.41055.1332323139392.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (OAK-33) Values in oak-core
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/OAK-33?page=3Dcom.atlassian.jir=
a.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13234299=
#comment-13234299 ]=20

Michael D=C3=BCrig commented on OAK-33:
----------------------------------

Also +1 for (C).=20

I think we should have a single internal value representation which also wo=
rks for the jcr bindings, which easily inter-operates with JSON and with JC=
R values and which avoids copying of values as much as possible. Currently =
I use JsonValue in the jcr bindings for that purpose. JsonValue is basicall=
y a pre parsed Json value and I think we should replace this with a more su=
itable representation.=20
               =20
> 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 an=
d 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, an=
d I fear the code would get unnecessarily complex, not as efficient as it c=
ould get (specially when dealing with numbers), memory usage would be highe=
r.
> 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 ab=
le 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), bu=
t 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 bac=
kend" (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 administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira