Proposal for Value Handling (oak-jcr and oak-core)

[Angela Schreiber <an...@adobe.com>]

hi all

as discussed recently in revision rev. 1329281 [1] i added a
new implementation of ValueFactory and Value/Binary in oak-jcr that
is based on value handling exposed by oak-api.

my goal was to address both the needs from jcr (API contract)
and oak-core (ability to detect value types for validation)
without adding significant overhead in terms of value conversion
and object creation.

i didn't yet perform additional tests since i would like to get
your feedback first.

for the same reason i did neither remove CoreValue/*Factory that
is present in oak-core/query package nor the Scalar interface
present in the oak-api (and it's usages)

here some further details:

- JCR Value and ValueFactory are intended to be thin wrappers
   around the corresponding objects being exposed by the oak-api.
   they are in charge of dealing with session-wide namespace
   remapping and any other kind of conversion from JCR level
   name/path to 'internal' name/path representation.

- Since the JCR namespace/name/path handling is work in progress
   i simply added a DummyNamePathResolver class to the implementation,
   just to indicate what needs to be done there.

- note, that value conversion is mostly delegated to the implementation
   in oak-core (except for those cases that need to respect name/path
   stuff and date conversion. for boolean-conversion i have to look up
   the API contract again in order to simplify it on oak-jcr).

- in the oak-API i added CoreValue and CoreValueFactory borrowing the
   names thomas used within the query. please let me know, if you have
   a better one :)
   the methods present on those interfaces are a subset of what is
   present in JCR but still allow to perform validation in terms
   of jcr value types.

- oak-api property types: for simplicity i currently just used the JCR
   property type constants... we may want to discuss if we should
   redefine them on oak-api.

- with thomas help, i also added an initial draft for binary support.

i am looking for your comments/concerns. my next step would be to
add some more tests and replace scalar and corevalue in oak-core/query.

kind regards
angela

[1] http://svn.apache.org/viewvc?rev=1329281&view=rev

Re: Proposal for Value Handling (oak-jcr and oak-core)

[Angela Schreiber <an...@adobe.com>]

hi all

> as a next step i will address the last major issue in this
> area: encoding non-json property types before writing to
> the MicroKernel (currently in KernelRoot#encode) and the
> other way round (currently in KernelNodeState#readValue).
>
> in a first step i will move both methods to a utility since
> IMO they belong together. my preference was to have the
> encoding in the property value.

done. the type hint added as prefix to the value.

> michael in addition suggested to handle it differently for
> multi-valued properties: add the type hint as first entry
> in the array. that would prevent having different types in
> the array and would nicely solve the issue of empty-array
> properties in JCR.

i didn't do this up to now as it would require changes to
Tree, PropertyState etc. not sure if the effort is really justified
given the fact that it's an rare edge case IMO and the property type
may even be guessed from the property definition... i will take a
look at this again, once we have the node type stuff implemented.

> once this is completed, we should basically be able to remove the
> @Ignore tags with special-type property-tests and enable

done... except for type of mv-properties and the reference/weakreference
properties that are both relying on node types being supported.
for the (weak)references we need uuid-lookup in addition.

> quite some tests from TCK that deal with value-conversion etc.

unfortunately not, as the TCK tests the node definition in
the setup (-> node types...).

so, i would be really good if you could add support for the
built-in node types soon.

kind regards
angela

Re: Proposal for Value Handling (oak-jcr and oak-core)

[Angela Schreiber <an...@adobe.com>]

hi all

to keep everyone in the loop just a short update on this issue:

in order to get a better feeling for the value story i continued
working on this:

- replacing the extra implementation in the query package and
   in oak-jcr/query by the API CoreValue in revision 1329612 [1].

- replacing Scalar by API CoreValue in revision 1329741 [2].
   both Scalar and ScalarImpl are still present but i
   added a TODO in order to clarify this.

as a next step i will address the last major issue in this
area: encoding non-json property types before writing to
the MicroKernel (currently in KernelRoot#encode) and the
other way round (currently in KernelNodeState#readValue).

in a first step i will move both methods to a utility since
IMO they belong together. my preference was to have the
encoding in the property value.
michael in addition suggested to handle it differently for
multi-valued properties: add the type hint as first entry
in the array. that would prevent having different types in
the array and would nicely solve the issue of empty-array
properties in JCR.

once this is completed, we should basically be able to remove the
@Ignore tags with special-type property-tests and enable
quite some tests from TCK that deal with value-conversion etc.

kind regards
angela


[1] http://svn.apache.org/viewvc?rev=1329612&view=rev
[2] http://svn.apache.org/viewvc?rev=1329741&view=rev


On 4/23/12 5:41 PM, Angela Schreiber wrote:
> hi all
>
> as discussed recently in revision rev. 1329281 [1] i added a
> new implementation of ValueFactory and Value/Binary in oak-jcr that
> is based on value handling exposed by oak-api.
>
> my goal was to address both the needs from jcr (API contract)
> and oak-core (ability to detect value types for validation)
> without adding significant overhead in terms of value conversion
> and object creation.
>
> i didn't yet perform additional tests since i would like to get
> your feedback first.
>
> for the same reason i did neither remove CoreValue/*Factory that
> is present in oak-core/query package nor the Scalar interface
> present in the oak-api (and it's usages)
>
> here some further details:
>
> - JCR Value and ValueFactory are intended to be thin wrappers
>     around the corresponding objects being exposed by the oak-api.
>     they are in charge of dealing with session-wide namespace
>     remapping and any other kind of conversion from JCR level
>     name/path to 'internal' name/path representation.
>
> - Since the JCR namespace/name/path handling is work in progress
>     i simply added a DummyNamePathResolver class to the implementation,
>     just to indicate what needs to be done there.
>
> - note, that value conversion is mostly delegated to the implementation
>     in oak-core (except for those cases that need to respect name/path
>     stuff and date conversion. for boolean-conversion i have to look up
>     the API contract again in order to simplify it on oak-jcr).
>
> - in the oak-API i added CoreValue and CoreValueFactory borrowing the
>     names thomas used within the query. please let me know, if you have
>     a better one :)
>     the methods present on those interfaces are a subset of what is
>     present in JCR but still allow to perform validation in terms
>     of jcr value types.
>
> - oak-api property types: for simplicity i currently just used the JCR
>     property type constants... we may want to discuss if we should
>     redefine them on oak-api.
>
> - with thomas help, i also added an initial draft for binary support.
>
> i am looking for your comments/concerns. my next step would be to
> add some more tests and replace scalar and corevalue in oak-core/query.
>
> kind regards
> angela
>
> [1] http://svn.apache.org/viewvc?rev=1329281&view=rev
>

Re: Proposal for Value Handling (oak-jcr and oak-core)

[Angela Schreiber <an...@adobe.com>]

corrigenda:

> rev. 1329281

Revision: 1329293
URL: http://svn.apache.org/viewvc?rev=1329293&view=rev

:)