Ian McNicoll MMS wrote: >> >> Either there is a documented interface to a persistence layer, or >> there isn't. >> It is quite possible I missed it in the documentations >> But till now, I asked it three times in three days, is there a >> documented interface to a persistence layer? Or do I have to puzzle >> it myself, which is possible, but I do not want to invent a wheel >> which is already there. >> > > As far as I am aware there is no fixed specification for a persistence > layer. From a brief chat to Thomas he indicated that a variety of > database styles were being used in live projects e.g traditional > relational databases, 'shredded' row storage such as OpenSDE, OO > databases such as db40 and cache, XML file/stream storage or newer > hybrids such as Sql Server 2005. > > I suspect there is no correct way of doing this. It will depend on > circumstances and very rapidly changing persistence options. The whole > industry is moving to lessening the 'impedance' between structured OO > modeled code and the underlying persistence layer and as yet there > does not appear to be a single universally compelling option.
yes, all the above is true. Actually, we do have the intention of publishing various persistence mappings of the reference model, but we want them to be tested first. Two that I am involved with take the approach of using a set of P_xxx classes, e.g. P_OBSERVATION, P_SECTION etc, but when you hit small objects like OBSERVATION.data (of type HISTORY), we serialise that whole field into P_OBSERVATION.data: String (really a lump of XML). So you end up with about only 10 - 15 classes to persist, which appears to work much better in hibernate than having all those fine-grained objects like HISTORY, EVENT, CLUSTER, ELEMENT, and all the DATA_VALUEs. There is never any gain in having such fine-grained objects in a persistent layer (although in some ODBs there is not much performance hit for doing it). The second exercise we are testing the use of a P_COMPOSITION class only in a .Net environment, i.e. same approach but even coarser grain. In both cases, you have to add special queryable attributes (i.e. columns) to enable querying to work. These approaches are not new of course, but I feel that we should see some of this stuff working in software before we put it out as specifications. ANyone who wants to contribute persistence mappings or schemata is welcome to do so - we will post them somewhere on the website, and when they can be validated in implementation, they will become a candidate for a more formal specification for the relevant persistence technology. - thomas
