jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Proposal for Value Handling (oak-jcr and oak-core)
Date Tue, 24 Apr 2012 14:29:11 GMT
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
>

Mime
View raw message