Component Design Question

[Gregor Zurowski <gr...@zurowski.org>]

Hi Everyone:

A recent discussion on the camel-users list [1] showed that the
camel-jcr component needs some enhancements to better support
real-world use cases. I would like to add query functionality, so that
users are able to submit JCR-SQL or JCR-XPath queries and retrieve
matching nodes. A possible implementation could look as follows:

- Add support for new values to CamelJcrOperation header with the
names "JcrQuerySql" and "JcrQueryXPath" for triggering queries by the
producer.
- The actual query is read from the body of the IN message.
- Matching nodes are returned in the body of the OUT message.

The question is how to return the resulting nodes? I considered the
following approaches:

1) Simply return an array of strings where each string is the UUID of
a matching node, e.g. [c042662a-f5be-11e3-8344-b2227cce2b54,
c0426b5c-f5be-11e3-8344-b2227cce2b54, ...]. The downside of this
approach is that the client would need to submit follow-up requests
for each UUID (e.g. with the CamelJcrGetById operation).

2) Return a list of javax.jcr.Node [2] instances of all matching
nodes. This is similar to what the current consumer implementation
returns (which is a list of javax.jcr.observation.Event instances).

3) Return a list of custom items. Each item is a translated version of
the javax.jcr.Node type where each field was converted into a common
Java type (similar to what the camel-cmis component is doing when
translating CMIS query results into a List<Map<String, Object>> data
structure).

What would be the best approach to return query results by the
producer, i.e. what would be the Camel-way of returning the results?

Thanks in advance,
Gregor

[1] http://camel.465427.n5.nabble.com/Camel-JCR-examples-td5746406.html
[2] http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Node.html

Re: Component Design Question

[Matt Sicker <bo...@gmail.com>]

Having type converters available for everything helps a lot in minimising
the need to worry about return formats. You could by default return the
native Node objects and provide type converters to List<Map<String,
Object>>.


On 17 June 2014 20:54, Gregor Zurowski <gr...@zurowski.org> wrote:

> Hi Everyone:
>
> A recent discussion on the camel-users list [1] showed that the
> camel-jcr component needs some enhancements to better support
> real-world use cases. I would like to add query functionality, so that
> users are able to submit JCR-SQL or JCR-XPath queries and retrieve
> matching nodes. A possible implementation could look as follows:
>
> - Add support for new values to CamelJcrOperation header with the
> names "JcrQuerySql" and "JcrQueryXPath" for triggering queries by the
> producer.
> - The actual query is read from the body of the IN message.
> - Matching nodes are returned in the body of the OUT message.
>
> The question is how to return the resulting nodes? I considered the
> following approaches:
>
> 1) Simply return an array of strings where each string is the UUID of
> a matching node, e.g. [c042662a-f5be-11e3-8344-b2227cce2b54,
> c0426b5c-f5be-11e3-8344-b2227cce2b54, ...]. The downside of this
> approach is that the client would need to submit follow-up requests
> for each UUID (e.g. with the CamelJcrGetById operation).
>
> 2) Return a list of javax.jcr.Node [2] instances of all matching
> nodes. This is similar to what the current consumer implementation
> returns (which is a list of javax.jcr.observation.Event instances).
>
> 3) Return a list of custom items. Each item is a translated version of
> the javax.jcr.Node type where each field was converted into a common
> Java type (similar to what the camel-cmis component is doing when
> translating CMIS query results into a List<Map<String, Object>> data
> structure).
>
> What would be the best approach to return query results by the
> producer, i.e. what would be the Camel-way of returning the results?
>
> Thanks in advance,
> Gregor
>
> [1] http://camel.465427.n5.nabble.com/Camel-JCR-examples-td5746406.html
> [2] http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Node.html
>



-- 
Matt Sicker <bo...@gmail.com>