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
