Alexander Klimetschek wrote:
On Wed, Feb 17, 2010 at 21:58, Johann Sorel <[email protected]> wrote:
Sorry to kick in the discussion, I made an implementation of JCR last
septembre for our geographic information system.
While doing it I found one annoying point in the current specification.
If you can take a minute to read the following.
As you know all, jcr is designed to manage datas of basic types : double,
string, boolean, stream ...and so on.
That solves most needs for any kind of storage system. But in some cases
like ours we also store what I would
call "intelligent" objects, like mathematic functions, coordinate systems ,
objects that have more then just properties
fields, they have capabilities (methods to make it simple).
I believe most of you have already made a bit of Swing before, there is a
class MutableTreeNode with a getUserObject()
method used to retrieve the real object hiden behind the node.
My suggestion would be to have a similar approach in JCR. something like
unwrap() to acces the intelligent object on the node
if there is one of course.
JCR is great but infortunatly we seen that we can do nothing else then
copying informations, make statistics or search based on properties.
Which is mostly useless for us. We need to be able to access the objects
hidden behind the nodes,
objects that follow whatever else specification (GeoAPI specification in our
case) so that we can work with them.
I hope you see the point here.
Did you try Object Content Mapping (OCM) with JCR (eg. Jackrabbit OCM)?
In the end, the objects you want to store have fields that boil down
to the basic properties (and if sth doesn't fit well, there is always
string, which can be searched). Real object databases would be close
to what you have in mind, but they always have the advantage that the
data and fields/properties are not very visible, ie. there are no
generic, standardized ways to look at the data, independent from the
specific programming language they are designed for.
We only use jackrabbit JCR commun module, and we don't intent to use any
more
module or we will lose all our cache structure (duplicate would be more
extact).
The problem is not the storage anyway.
let's take an exemple :
Imagine Liferay for exemple, 2 companies manage somehow to expose
repositories
in liferay by adding each one a plugin. thoses repositories are now
visible by any portlet in liferay. Each
repository have geographic datas clearly defined by a well knowned Node
type.
Now you add a mapping jsf portlet made by a third company that can
access thoses repository and can render
any object that match this node type. problem is, the attributs are not
enough to render a map, he needs acces to
the hidden object, objects that follow another specification.
But unfortunatly he can't since not method on the JCR node interface can
give him this object.
Using JCR is a bit like being in front of a no entrance bunker,
informations are exposed through a small perfectly formatted window.
The bunker has a big sign writen : "hospital", ho! great I'm a doctor, I
can talk my own language (specification) with them (100times more
efficient) but how do I get in ? there is no entrance.
I believe there is a need for this door otherwise JCR will be
incompatible with any other specification.
sorry if my english is not perfect.
johann sorel
