First of all, thank you for creating this project and publishing it under an Apache-style license. I hope it becomes the de-facto standard for Topic Maps in Java.
Before I get to my question, some background: I work for a company that specializes in Content Integration software. One aspect of our product suite allows users to associate content (stored images, multi-media, URLs, etc.) using a hierarchical, "virtual repository" metaphor. Topic Maps seems to be a good fit to extend our association engine to allow arbitrary, non-hierarchical associations between content items (our topics).
We currently use the JDO paradigm (specifically, FastObjects) as our back-end storage for "virtual repositories". We are very satisfied with this storage solution and would like to maintain it, but are looking to possibly leverage tm4j internally. This would require that tm4j have a JDO-compliant backing (in the same way that there is a memory backing and an Ozone backing). JDO is intented to provide transparent persistence in Java. In theory, any normal Java class can be made persistence capable. In practice, this restricts the class in a few ways, for example the class must provide a no-arg constructor, and the class must use JDO-compatible members declarations (e.g. Set instead of HashSet).
Now, to the questions at hand: Are you familiar with the JDO specification at all? Have you considered persisting tm4j topic maps using JDO? Would you consider modifying the memory implementation (or perhaps accepting our modifications to the memory implementation) to make it persistence capable? I'm just trying to feel out the prospects of using tm4j with JDO, and whether there is interest in collaboration on this matter.
Thanks for your time,
--Andy Jenkins
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did look at using JDO for TM4J's persistence, but when I looked (a couple of months or so ago) I couldn't find any complete open-source JDO implementations. There are one or two projects working on JDO implementations, but no-one seems to have anything stable right now.
I would certainly be happy to consider the modifications necessary to make the in-memory implementation persitence capable if you would like to contribute that.
Cheers,
Kal
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the quick response. After talking with some folks on my end, I don't think the naive approach to JDO support I described above would work for our circumstance. We may look into developing an implementation, but it would probably be more of a rewrite (rather than a tweak of) the memory model.
--Andy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Take a look at the way that the Hibernate back-end is implemented. This is done by wrapping a simple data-model (the XXXDataObject.java classes) in runtime wrapper classes that implement the more complex behaviours (often in terms of queries against the data store). I think that this would be the way to go with a JDO implementation too. I had originally planned to make the data objects approach a bit more storage-independent so that it would be easy to add JDO support later, but things got kind of complicated and I went for the path of least resistance. Still, I think you might find it a good starting point.
Cheers,
Kal
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First of all, thank you for creating this project and publishing it under an Apache-style license. I hope it becomes the de-facto standard for Topic Maps in Java.
Before I get to my question, some background: I work for a company that specializes in Content Integration software. One aspect of our product suite allows users to associate content (stored images, multi-media, URLs, etc.) using a hierarchical, "virtual repository" metaphor. Topic Maps seems to be a good fit to extend our association engine to allow arbitrary, non-hierarchical associations between content items (our topics).
We currently use the JDO paradigm (specifically, FastObjects) as our back-end storage for "virtual repositories". We are very satisfied with this storage solution and would like to maintain it, but are looking to possibly leverage tm4j internally. This would require that tm4j have a JDO-compliant backing (in the same way that there is a memory backing and an Ozone backing). JDO is intented to provide transparent persistence in Java. In theory, any normal Java class can be made persistence capable. In practice, this restricts the class in a few ways, for example the class must provide a no-arg constructor, and the class must use JDO-compatible members declarations (e.g. Set instead of HashSet).
Now, to the questions at hand: Are you familiar with the JDO specification at all? Have you considered persisting tm4j topic maps using JDO? Would you consider modifying the memory implementation (or perhaps accepting our modifications to the memory implementation) to make it persistence capable? I'm just trying to feel out the prospects of using tm4j with JDO, and whether there is interest in collaboration on this matter.
Thanks for your time,
--Andy Jenkins
Hi Andy,
I did look at using JDO for TM4J's persistence, but when I looked (a couple of months or so ago) I couldn't find any complete open-source JDO implementations. There are one or two projects working on JDO implementations, but no-one seems to have anything stable right now.
I would certainly be happy to consider the modifications necessary to make the in-memory implementation persitence capable if you would like to contribute that.
Cheers,
Kal
Kal,
Thanks for the quick response. After talking with some folks on my end, I don't think the naive approach to JDO support I described above would work for our circumstance. We may look into developing an implementation, but it would probably be more of a rewrite (rather than a tweak of) the memory model.
--Andy
Andy,
Take a look at the way that the Hibernate back-end is implemented. This is done by wrapping a simple data-model (the XXXDataObject.java classes) in runtime wrapper classes that implement the more complex behaviours (often in terms of queries against the data store). I think that this would be the way to go with a JDO implementation too. I had originally planned to make the data objects approach a bit more storage-independent so that it would be easy to add JDO support later, but things got kind of complicated and I went for the path of least resistance. Still, I think you might find it a good starting point.
Cheers,
Kal