В настоящее время я пишу простое приложение для тестирования, которое будет просто запрашивать sdo_geometry из базы данных, используя Oracle OCI в C ++. У меня возникли некоторые проблемы с поиском хорошего примера того, как именно выполнить, так как это sdo_geometery является сложным типом. Есть некоторые замечания об использовании типа SQL коллекции, но ничего конкретного.
Мой код основан на проекте adpoci, который можно найти здесь: https://github.com/ReneNyffenegger/development_misc/tree/master/c%2B%2B/oci/adpoci
Однако мне нужно расширить этот пример, чтобы запросить sdo_geometry.
select mdsys.sdo_geometry (2003,
NULL,
NULL,
mdsys.sdo_elem_info_array (1, 1003, 1),
mdsys.sdo_ordinate_array (1,1,2,1,2,2,1,2,1,1))
from dual;
любая помощь будет принята с благодарностью.
Да, это сложно. Я сделал это давным-давно, но, к сожалению, у меня нет такого способа, которым я мог бы легко поделиться (все это завернуто в проприетарный слой C ++ поверх OCI). Для любых пользовательских типов Oracle (UDT) вы обычно используете Тип объекта Переводчик (OTT) для генерации структур C (для значений и индикаторов), которые вы связываете и определяете. Я включил ниже те, которые я использовал в то время (11gR1), которые, как я ожидаю, будут по-прежнему действительны, но в идеале вы должны прочитать об объектно-реляционных аспектах OCI и сгенерировать их самостоятельно.
struct sdo_point_type {
OCINumber x, y, z;
};
struct sdo_point_type_ind {
OCIInd _atomic;
OCIInd x, y, z;
};
struct sdo_geometry {
OCINumber sdo_gtype;
OCINumber sdo_srid;
sdo_point_type sdo_point;
OCIArray* sdo_elem_info;
OCIArray* sdo_ordinates;
};
struct sdo_geometry_ind {
OCIInd _atomic;
OCIInd sdo_gtype;
OCIInd sdo_srid;
sdo_point_type_ind sdo_point;
OCIInd sdo_elem_info;
OCIInd sdo_ordinates;
};
Чтобы связать / определить, вам нужно TDO для UDT. Вот код, который я использовал для этого:
/*!
* \brief Looks up raw OCI type descriptor for a given SQL type name.
*
* \param type_name the possibly qualified type name. Note that
* types are implicitly capitalized by Oracle Server when
* defined, and thus type_name should usually be uppercase only.
* \a type_name can be qualified, as in "MDSYS.SDO_GEOMETRY", or
* unqualified as in "MY_TYPE", in which case it is looked up in
* the current user's schema.
* \return the object type, either obtained from the server when
* the type is looked up for the first time, or from a cache
* this connection keeps. Note that the return type is valid
* only for this connection, and only as long as this connection
* is valid itself.
* \throw std::runtime_error if the type cannot be found.
*/
OCIType* Connection::get_object_type(const char* type_name) {
typedef std::map<std::string, OCIType*> TdoMap;
TdoMap::iterator tdo_iter = tdo_map_.find(type_name);
if (tdo_iter != tdo_map_.end()) {
// return type already in the cache
return tdo_iter->second;
}
// lookup the type for the first time
OCIType* tdo = 0;
OraTextString tdo_name(type_name);
const sword rc = OCITypeByName(
env_->envhp(), errhp(), svchp(),
0, 0, // schema name (default schema when 0)
tdo_name.text, tdo_name.length,
0, 0, // version name (ignored)
OCI_DURATION_SESSION,
OCI_TYPEGET_ALL,
&tdo
);
checkerr(rc, errhp());
// add it to the cache before returning it
tdo_map_.insert(TdoMap::value_type(type_name, tdo));
return tdo;
}
Затем вы связываете / определяете, используя тип SQLT_NTY, и OCI вызывает объекты. Например:
OCIType* tdo = conn.get_object_type(tdo_name);
// WARNING: Addresses passed to OCIBindObject *MUST* still be valid
// *after* OCIStmtExecute, so cannot be addresses to local(stack) vars.
checkerr(
OCIBindObject(
bind_hndl, errhp(), tdo,
(void**)&obj_ref.p_value_, 0, // value/indicator sizes
(void**)&obj_ref.p_indicator_, 0 // not used apparently...
),
errhp()
);
Обратите внимание, что вам нужно как обычное связывание / определение, а затем связывание / определение объекта. Снова, посмотрите документацию об объектно-реляционном OCI.
Затем вам нужно покопаться в экземплярах OCIArray *. SDO (Spatial) UDT на самом деле тоже не просты … Вот определения из моей обертки геометрии:
/*!
* \brief All possible geometries dimensions.
*/
enum Dimension {
TWO_D = 2, //! a 2D geomertry
THREE_D = 3, //! a 3D geomertry
FOUR_D = 4 //! a 4D geomertry
};
/*!
* \brief All possible types of geometries.
*/
enum Type {
CUSTOM_GEOMETRY = 0,
POINT = 1,
LINE = 2,
POLY = 3,
COLLECTION = 4, // heterogeous group of all other geometry types
MULTI_POINT = COLLECTION + POINT,
MULTI_LINE = COLLECTION + LINE,
MULTI_POLY = COLLECTION + POLY,
SOLID = 8,
MULTI_SOLID = 9
};
/*!
* \brief All possible type of geometry elements.
*/
enum ElementType {
CUSTOM_ELEMENT = 0,
POINT_ELEMENT = 1,
LINE_ELEMENT = 2,
EXTERIOR_POLY = 1003,
INTERIOR_POLY = 2003,
COMPOUND_LINE = 4,
EXTERIOR_COMPOUND_POLY = 1005,
INTERIOR_COMPOUND_POLY = 2005,
SURFACE = 1006,
SURFACE_HOLE = 2006,
SOLID_ELEMENT = 1007
};
/*!
* Meaning of the interpretation field for ElementType LINE.
*/
enum LineType {
SEG_LINE = 1,
ARC_LINE = 2
};
/*!
* Meaning of the interpretation field for ElementType
* EXTERIOR_POLY or INTERIOR_POLY.
*/
enum PolygonType {
SEG_POLY = 1,
ARC_POLY = 2,
RECTANGLE = 3,
CIRCLE = 4
};
/*!
* \brief A triplet describing a element (piece) of this geometry.
*
* A geometry is composed of elements which are described by one or
* more info elements, each refering to zero or more ordinates.
*/
struct PDGM_OCI_API ElemInfo {
/*!
* \brief the element's type.
*
* Valid values are: 0, 1, 2, 1003, 2003, 4, 1005, 2005, 1006, 2006, 1007.
*/
ub2 type;
/*!
* \brief The offset in the ordinate array
* at which this element's coordinates starts.
*
* The end offset is determined either via the element-specific
* interpretation field, or the offset for the next ElemInfo.
*
* The maximum size of the ordinate array is 1,048,576 (1024^2).
*
* Note that persistent offsets are 1-based in Oracle, but this
* offset is transparently adjusted to be 0-based.
*/
ub4 offset;
/*!
* \brief The number of ordinates corresponding to this element.
*
* For example, a 2D rectangle has only 4 ordinate, for the x,y
* of its lower-left and upper-right corners.
*
* Note that some elements have no ordinates, for example a compound
* line string has an initial element info which introduces and precedes
* the info elements each each line string, but itself has no ordinates
* per se, only its composed line-strings refer to ordinates.
*/
ub4 ordinate_count;
/*!
* \brief element-specific \em detail about this element.
*
* I'm assuming this is an integer, but could be any number in fact...
*
* For an ElemInfo of type 1 (point or vector or multi-point),
* interpretation can be 0 (vector, and thus ordinates must contain
* two points, the second normalized), 1 (single point), or N > 1
* (multi-point) where N is the number of points.
*/
ub4 interpretation;
ElementType get_type() const {
return ElementType(type);
}
};
Как видите, это определенно неочевидно. Oracle Spatial в C ++ OCI слишком много времени, чтобы получить права, и много чтения документации и экспериментов.
Надеюсь, что выше поможет вам немного. Удачи, -DD