On Wed, Feb 17, 2010 at 21:58, Johann Sorel <johann.so...@geomatys.com> 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. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
