How can I use XxxStringADTClass? (Or can't I?) I want to use variable length strings in my ADT's but so far I have only managed to succeed with character arrays. I've browsed the code a little, and I have not found any methods to convert a XxxStringADTClass from/to char*. We currently have not provided structuring mechanisms to build E-ADTs from the existing ones. The next release will contain struct types for this. Each XxxADTClass encapsulates the behavior of a Predator data type. If you are building a new data type, you should build a separate subclass of XxxADTClass. Sounds like you need a class which (like XxxStringADTClass) is not fixed-size.
How do I declare arrays or hashtables or anything using pointers in its memory representation for Predator? Is it sufficient to provide the TypeCopy method? (I would actually like to use STL, but any hashtable implementation would do...) It is the responsibility of the person writing the ADT to convert in-memory representations and on-disk representations. We should probably specify a Serialize() method. As far as Predator is concerned, all objects have the same representation in memory and on disk (in other words, no swizzling happens when data is read into memory). Each E-ADT needs to convert its values into in-memory forms before using them in a function. A good example of this is the image E-ADT (note the methods getMemImage and putMemImage). This may seem strange from the oo-dbms viewpoint, where everything is swizzled, but consider that in most or-dbms queries, one hopes that the majority of large objects never get manipulated (for instance, a query over a large table of images may only be interested in a few of them).
I need to disable the 2P page level locking that is provided by default (apparently by Shore). Is this possible by simply changing some part of Predator code, instead of the Shore code? I tried to change the smOptions (line 33, utils/shoresm.C) constructor arg to 0 and 1, but it does not help. We have not yet gotten around to providing a Predator level mechanism to change locking methods, so you will have to look at the Shore web pages for the appropriate code changes for now. The documentation should be able to tell you what is needed to specify tuple level locking.