Hi Norman, Thanks for the detailed feedback and rationale.
The registry is really designed to store *arbitrary* content .. as such there's really no special storage handling for any type of data. As Paul said in his reply its certainly possible to implement an ORMRegistry (and we'd definitely welcome such a contribution), but I don't quite get it. Do you expect to look at the media type of the resource being stored to figure out how to map the data into a certain object type and then use the ORM mapper to store that into the database? We currently don't "deserialize" any resource before we store it .. we treat it at a blob of bytes and drop it in. That of course comes at a cost- you can't query into structured resources, but it make the registry highly scalable to anything.
That's not to say you couldn't implement a custom backend (per Paul's suggestion) that did JPA to map types that you cared about into a different database format and stored them differently. You could probably inherit from the JDBCRegistry impl and extend it and override just the bits you want to.
Bye, Sanjiva. Norman Barker wrote:
Hi, I downloaded the registry release, and it works great in JBoss and I really like the web interface so I downloaded the code as well. I was surprised to see that it wasn't using an ORM mapper since with simple JPA mappings you can switch between hibernate and OpenJPA without too much of a problem (I have just ported a large project from JBoss to WebLogic (hibernate -> OpenJPA). I also saw that this was discussed on the list in some depth - but unfortunately it immediately makes the registry less appealing to me and it is tempting just to use the abdera servlet example ... What would it take to add an ORM persistence engine (if you give me a class name I will try writing the code). My reasons for wanting to use ORM tools is that it would be useful to support complex database objects (e.g. GML documents, store the XML descriptions of the geometry as spatial geometry objects) there has been a lot of work (and indeed I wrote the hibernate code for PostGIS) to map these in the database and utilise the spatial index. Hibernate criteria queries, and dialects (again for spatial functions) are very useful. The license for hibernate as opposed to Apache is an issue, but JPA is a specification for annotations and can port across implementations. I am thinking that writing generic indexing services will be a lot easier with ORM tools since the indexing service does not have to worry about the underlying database engine. without ORM I don't see the benefit of this implementation of the registry as it seems to have ignored the big steps taken forward by EJB3, take for example the container port I have just performed, pointbase is the DB for weblogic (a major vendor!) and I can't just do it if I am dependent on a SQL create script (well actually we probably could), but with JPA a user wouldn't have to worry (so much). Don't want to knock the development effort, and the web interface is really nice and the concept is great, just want to give some feedback now, and if you point me at the right place (and you want it done - I can add the ORM code). Finally, I made the comment on Paul Freemantle's blog, the big benefit of ebRIM is resource associations, owner->dataset, service->dataset etc. How is this being envisaged for the registry? Great effort, and thank you - registries are a very hot topic in the geospatial world. thanks, Norman _______________________________________________ Registry-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
-- Sanjiva Weerawarana, Ph.D. Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ email: [EMAIL PROTECTED]; cell: +1 650 265 8311 | +94 77 787 6880 "Oxygenating the Web Service Platform." _______________________________________________ Registry-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
