How to properly create complex OCI objects (for Annotation Text)

Question

I am upgrading a tool that will upload text objects to a table with a ST_ANNOTATION_TEXT field. The app is a C++ app and I need to instantiate a ST_ANNOTATION_TEXT (using OCIObjectNew??). I actually have 2 questions. First, does anyone have an example of how to accomplish this? I seem to be unable to correctly create the annotation text type in C++ to be able to append to (calling OCICollAppend). Second, since ST_ANNOTATION_TEXT is a complex type (contains an array of annotation text elements), do I need to call OCIObjectNew on not only the main ST_ANNOTATION_TEXT type but also for the ST_ANNOTATIONTEXTELEMENT_ARRAY, ST_ANNOT_TEXTELEMENT_ARRAY, and the ST_ANNOTATIONTEXTELEMENT?
I can't seem to find in info on this so hopefully someone else has been through this.

Answer 1

user3068343 wrote:
I am still having an issue where the sub objects are still NULL.Actually I was mistaken. I must have confused getting an Object from OCIObjectNew with using one of its constructor method in a statement.
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci18nav004.htm#sthref3438 clearly state the object will have NULL attributes, unless the OCI_ATTR_OBJECT_NEWNOTNULL flag is set on the environment handle.
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci11obj.htm#i446308 further tells you what the default value for the object members will be.
An older 9i doc http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96594/adobjadv.htm#1008774 also warns about resetting the indicator struct member when you update a member of the object.
user3068343 wrote:
++a) you allocate the object's top-level struct yourself (SDO_GEOMETRY in my case) in C+++
Above you suggest creating the objects top-level struct myself. How do you create that top level object? I have been using OCIObjectNew on that object as well as its sub objects? Is that how you are creating the top-level object?This technique works only on binds, as objects you get back from defines are always allocated from the object cache. I create the top-level object directly on the stack... This is something I discovered worked, but is not documented, so you're probably on safer ground using OCIObjectNew instead.
BTW, the reason I can't easily post OCI example code is that my code uses wrappers around the objects that hides most of the OCI:
Geometry Geometry::make_point(OCIEnv* envhp, OCIError* errhp, float x, float y) {
    Geometry point_geom(envhp, errhp);
    point_geom.set_null(false);
    point_geom.gtype() = 2001;
    PointRef point = point_geom.point();
    point.set_null(false);
    point.x() = x;
    point.y() = y;
    return point_geom;
}The above creates an 2D point-type SDO_GEOMETRY hidden inside the Geometry class, itself deriving from a GeometryRef class. The latter wraps a C++ API on top of the struct pointers for a SDO_GEOMETRY/SDO_GEOMETRY_ind, while Geometry actually composes the OTT generated value/indicator structs by value, and passes addresses to its nested structs to GeometryRef (its parent class). So GeometryRef can manipulate an object irrelevant of where it was allocated, the stack or the object cache. The Geometry class is a value class, but it's useful for binds only, and like I said uses a behavior which appears to work but is not explicitly documented.
Unless you have nested objects by reference, nested objects are composed by value in the OTT-generated structs, so the space for all nested objects is already allocated after the first OCIObjectNew. But the members themselves are not initialized, and thus marked as null in the indicator struct.
In the code above, my Geometry instance is fully allocated (on the stack), but fully uninitialized (the indicator is by default set to all nulls). I first set the atomic flag to non-null, then get the Ref wrapper around its nested SDOPOINT_TYPE to also set it to non-null, and fill in the x/y member (via another NumberRef wrapper, which knows about the member and the indicator for that member, and sets it as non-null when assigned to). Notice how how I return the instance by copy: My point geometry instance doesn't have a pointer-aliasing issue here, only because its two OCIColl* are null. In the general case, you can't copy my value wrappers without making a true deep copy... But I'm getting into the weeds here.
The important point is that OCIObjectNew doesn't init the nested objects unlike what I stated earlier. Sorry for misleading you on that. --DD