Java Step by Step
‘Build an object database’
Merlin Hughes and Michael Shoffner
LETTER_HEAD: Object Persistence Layer — an object-oriented approach to databases
Merlin,
I enjoyed your article because I’m working on OPL (Object Persistence Layer), a part of the Turbine project at https://www.apache.org. OPL is an object-oriented approach to relational databases. It’s based on a design by author and consultant Scott Ambler that appeared in Software Development in 1998.
It’s interesting for me to compare and contrast the your approach with Ambler’s. My role on the project to put Ambler’s ideas into code. He does not share his code, and, of course, in many areas, his paper is only a rough outline.
George
AUTHOR_REPLY:
George,
Thanks for the feedback. I had a look at the Turbine and OPL stuff; it looks very interesting. I also had a look at Ambler’s paper; I’ve not seen his stuff before. The JavaWorld article obviously falls far short of the full scope that he proposes, but I think that it is an interesting start.
I’m not sure I agree with him on everything. For instance, I don’t like method accessors. I think it is far less intrusive to set the variables directly, à la serialization. Obviously, this screams out for a method akin to readObject()
that would allow the object to perform post-reconstructive surgery on itself. Also, my framework could perhaps do with a distinction among the fields from each class in an inheritance hierarchy, as this would allow more flexibility in the backend tables used. Moreover, there’s the option of a writeObject()
look-alike, which would allow an object to store a decent representation of nonrepresentable fields (references, and so forth). The list goes on.
Anyway, thanks again for the feedback; I’ll be sure to give Turbine a whirl sometime.
Merlin Hughes
:END_REPLY
LETTER_DIV:
LETTER_HEAD: Can classes with collection attributes persist?
Merlin,
Using your code, can you persist classes that have collection attributes (map
, set
, and so on)? For instance:
class myclass {
String name;
HashMap myMap;
TreeSet myTreeSet;
}
Would you be able to persist an instance of the above class and restore it?
Daryoush Mehrtash
AUTHOR_REPLY:
Daryoush,
The code in its current form cannot persist collections; all it can persist are strings and primitives. However, it would not be impossible to add support for other types — such as collections — so long as you can come up with a good database representation. Representing map
s and set
s as part of a database record would not necessarily be trivial, except, perhaps, if you represent them as manually encoded text.
Merlin Hughes
:END_REPLY
LETTER_DIV:
LETTER_HEAD: How to resolve an InstantiationException in the ReflectionStorer.setFields() method
Merlin,
Your article is very interesting. I downloaded the full source code and played around with StorageTest.java
. When I use ReflectionStorer
instead of the SerializationStorer
in this program, without changing the rest of the code, I keep getting an InstantiationException
at the ReflectionStorer.setFields()
method.
I made only a one change to the StorageTest.java
code. Here is the original line:
ObjectStorer storer = new SerializationStorer (storage);
And here is the new line:
ObjectStorer storer = new ReflectionStorer (storage);
Is this a bug? Or is there something I’m missing?
Alok
AUTHOR_REPLY:
Alok,
Sorry — you found a small omission in the ReflectionStorer
code. I simply use Class.newInstance()
to create objects; the code should in fact use the Constructor
class in order to enable access to private constructors.
In the ReflectionStorer
class, in place of:
Object object = clazz.newInstance ();
Put:
Object object;
try {
Constructor cons = clazz.getDeclaredConstructor (new Class[0]);
cons.setAccessible (true);
object = cons.newInstance (new Object[0]);
} catch (NoSuchMethodException ex) {
throw new InstantiationException ("No null constructor");
} catch (InvocationTargetException ex) {
throw new InstantiationException ("Constructor exception: " +
ex.getMessage ());
}
If you make these changes, you can make the constructor accessible before actually calling it.
Merlin Hughes
:END_REPLY