You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by "Thomas Mueller (Created) (JIRA)" <ji...@apache.org> on 2012/03/21 10:45:39 UTC
[jira] [Created] (OAK-33) Values in oak-core
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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Thomas Mueller (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Jukka Zitting (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234351#comment-13234351 ]
Jukka Zitting commented on OAK-33:
----------------------------------
bq. multi-valued properties
As the name says, I think we should handle that at the property abstraction level where we should have two kinds of properties: single- and multi-valued ones. Calling the value abstraction {{Scalar}} should make that clear.
> 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Michael Dürig (Commented JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234346#comment-13234346 ]
Michael Dürig commented on OAK-33:
----------------------------------
> 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.
Ack wrt. the issue with multi valued properties. If we go down the same route I chose for JsonValue (i.e. algebraic data types) we shouldn't use Scalar and Vector for the concrete types and come up with a better name for the abstract value type. I.e.:
{code}
abstract class Value {
class Scalar extends Value{}
class Vector extends Value{}
}
{code}
> 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Michael Dürig (Commented JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234299#comment-13234299 ]
Michael Dürig commented on OAK-33:
----------------------------------
Also +1 for (C).
I think we should have a single internal value representation which also works for the jcr bindings, which easily inter-operates with JSON and with JCR values and which avoids copying of values as much as possible. Currently I use JsonValue in the jcr bindings for that purpose. JsonValue is basically a pre parsed Json value and I think we should replace this with a more suitable representation.
> 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
[jira] [Resolved] (OAK-33) Values in oak-core
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela resolved OAK-33.
-----------------------
Resolution: Fixed
Fix Version/s: 0.3
> 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
> Assignee: angela
> Fix For: 0.3
>
>
> 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Jukka Zitting (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234292#comment-13234292 ]
Jukka Zitting commented on OAK-33:
----------------------------------
bq. performance implications
A type-specific implementation class for numeric values will require significantly less memory and perform better than a generic one that needs a boxed object for the actual value.
bq. getInputStream() should always return a new stream
+1
> 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Michael Dürig (Commented JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236171#comment-13236171 ]
Michael Dürig commented on OAK-33:
----------------------------------
I committed and initial implementation of Scala in revision 1304130. I also started using it for KernelPropertyState. ScalarImpl has a few todos in the code which need further attention.
Furthermore when we want to add a method to PropertyState which returns a Scalar, we get a circular reference between mk and core.
> 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Jukka Zitting (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234365#comment-13234365 ]
Jukka Zitting commented on OAK-33:
----------------------------------
I committed a draft of such a Scalar interface in revision 1303394.
> 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Michael Dürig (Commented JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234817#comment-13234817 ]
Michael Dürig commented on OAK-33:
----------------------------------
I'd prefer the first option and factor the other conversions into a separate class. But I'd be fine with the second approach also.
> 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Thomas Mueller (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239412#comment-13239412 ]
Thomas Mueller commented on OAK-33:
-----------------------------------
Now I have replaced
oak-core / org.apache.jackrabbit.oak.query.ScalarImpl
oak-core / org.apache.jackrabbit.oak.query.ScalarType
with
oak-core / org.apache.jackrabbit.oak.query.CoreValue
> 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Michael Dürig (Commented JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234375#comment-13234375 ]
Michael Dürig commented on OAK-33:
----------------------------------
What troubles me a bit with handling multi-valued properties at property level is that this might affect a lot of places. We then need different method signatures for handling single values and multi values throughout the stack where we don't really care. Some sort of unification would be nice here.
Another (edge) case is typing: how do we express the type of empty multi valued properties?
> 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Thomas Mueller (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235676#comment-13235676 ]
Thomas Mueller commented on OAK-33:
-----------------------------------
About Scalar.getType():
We need some way to represent the type info (PropertyType.STRING,... PropertyType.DECIMAL), even if we convert some values to String internally in oak-core. Otherwise we would lose data, right?
For most part within oak-core, we could view the type of a scalar just as an opaque integer. But within the query engine, the data type does need to have a meaning, as using string comparison for numbers would be incorrect. What about using the same scalar types as we have property types? Or is this something that is only important for the query engine?
> 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Felix Meschberger (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234298#comment-13234298 ]
Felix Meschberger commented on OAK-33:
--------------------------------------
> OakValue, Scalar, Atom: all are fine for me
I happen to like Scalar. Atom sounds wrong and OakValue is too close to JCR "Value"
> The value abstraction should be expressed as an interface in .oak.api
I agree this to go into the API -- provided it is used outside of Oak Core (for example in the JCR implementation
layer).
Whether it be an interface or a concrete class, it depends on the use. I am fine for value (in the sense of Integer, Long, etc. value classes) classes to be exposed by the API. These are immutable and possibly even final (or at least not intended to be extended by client code). I see no issue with exposing them in an API. If there might be a open variety of implementations, maybe even custom implementations for special use cases, having an interface (in addition) might make sense.
> 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Thomas Mueller (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Jukka Zitting (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Assigned] (OAK-33) Values in oak-core
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela reassigned OAK-33:
-------------------------
Assignee: angela
> 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
> Assignee: angela
>
> 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
[jira] [Issue Comment Edited] (OAK-33) Values in oak-core
Posted by "Michael Dürig (Issue Comment Edited JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236171#comment-13236171 ]
Michael Dürig edited comment on OAK-33 at 3/22/12 11:27 PM:
------------------------------------------------------------
I committed and initial implementation of Scalar in revision 1304130. I also started using it for KernelPropertyState. ScalarImpl has a few todos in the code which need further attention.
Furthermore when we want to add a method to PropertyState which returns a Scalar, we get a circular reference between mk and core.
was (Author: mduerig):
I committed and initial implementation of Scala in revision 1304130. I also started using it for KernelPropertyState. ScalarImpl has a few todos in the code which need further attention.
Furthermore when we want to add a method to PropertyState which returns a Scalar, we get a circular reference between mk and core.
> 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Jukka Zitting (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234273#comment-13234273 ]
Jukka Zitting commented on OAK-33:
----------------------------------
+1 for (C)
Some comments:
* We should use some other name than Value (and ValueFactory) to avoid confusion with JCR. Some ideas: OakValue, Scalar, Atom
* The value abstraction should be expressed as an interface in .oak.api since we'll need to use it when passing data to and from clients.
* Binary values should be a part of this value abstraction, as otherwise we need to come up with another, parallel solution for binaries.
* I'd back binary values with an MK blob reference. There should be no other storage mechanism in oak-core.
> 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "Thomas Mueller (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (OAK-33) Values in oak-core
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OAK-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263563#comment-13263563 ]
angela commented on OAK-33:
---------------------------
the refactoring is completed. i would like to keep the issue until we have the
reference values implemented (and properly validated) as well.
in addition there are still some value related tck test failing. some of those
may be caused by missing validation on the oak-core level.
> 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
> Assignee: angela
>
> 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