Thanks a lot Bert and Tim and others, Tim, It will be interesting to explore your option. Object dbs are getting more popular now.
Bert, thanks for being very frank with the issues. I will think over the possibilites (vis-a-vis my still-small programming experience). I would support your open-source approach. I am (still) thinking of working on an open source project. I dont think anything stops anyone (openehr license-wise) from making an open persistence product. Another option might be xml persistence, xindice-based. but I fear the speed issues with xml (in large dbs). Cheers, Ime openehr-technical-request at openehr.org wrote: Ime Asangansi schreef: > HAPPY NEW YEAR!!! A bit early (13 hours to go to the new year, overhere), No problem. There are many possibilities for persistence-layers, all solutions have pro's and con's, for example - as Tim suggested, a object database - hibernate - mimic hibernate-architecture in code (this is a part of my solution, it is much work, but I have everything under control) - blob's in relational-database - hybride between blob's and relational - dump objects to XML - more hybrid's possible........ - add extra indexes for OLAP etc, etc. It also depends what your purpose is, and will be, how about scalability (small scale gives you possibilities which can better be avoided in large scale) But whatever you choose, you have to buy it or build it yourself, because no one is publishing his solution. If you build one by yourself, I like to advise you that you take the java-code as a good source of inspiration, but feel free to change small, but important things. The immutability in the java-kernel can sometimes stand in your way, when this happens to you.... My solution is therefore, use what is usable for you, but do not let your choice restrict you to that choice. I have build a persistence layer, first in hibernate, but there were some problems, I switched to my own solution. Best thing (IMHO) to achieve would be an abstract and small persistence layer, open sourced, to which the kernel can connect, and below, very many choices of possible solutions can connect. This would have some strong advantages: - the reference kernel could be used unchanged to everyone, it could really be shared code, which, for now, in my case, it is not - problems in design, which reflect to the kernel code, especially its immutability, could be solved, which are not solved now. I suggest this every three months on this list, but the discussion always dies without explicit mentioned reason. It is not that I give up, I can go my own way, no problem, the specs are in the documents, not in the reference java implementation, I use what I can use from the kernel, I thank Rong and others for their great job, but it is a pity, we can not work together. I believe, it is rather sensitive, because, when you publish a persistence-layer, you have a full blown product, which others can use, I think, people fear to put their self out of business if they publish too much knowledge. That, I beleive is the reason because the discussions about this subject often die. Those are my feelings about the situation, there is a chance that I am wrong. kind regards, and we, have a happy new year, in about 13 hours. Bert Verhees Why will you acquire so much informatics knowledge and not share... Contribute to http://www.wiki.ehealthpedia.org/ "A little more persistence, a little more effort, and what seemed hopeless failure may turn to glorious success" - Elbert Hubbard --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080101/814c408c/attachment.html>
