Weblog for the AMIS Technology corner
Posts tagged adt
Oracle SQL and PL/SQL: juggling with user defined types (ADT) and XMLType – for creating an ADT based XML Service API
Sep 4th
Packages in the Oracle Database are a fine construct to use for creating a service API at PL/SQL level – that through JDBC or other connections into the database can quickly be exposed at other levels than just internally for PL/SQL. A service API has a number of characteristics, that typically include a structured, well documented contract – definition for the data that goes in and comes out of the service -, complex, nested message structures and the ability to communicate in terms of XML.
Using ADTs or user defined types in the Oracle RDBMS is quite often very useful. Presenting such a service-style interface from PL/SQL packages is quite easily realized using custom type definitions – easier both for the definition of the package’s "service contract", the consumer of the package (at least the Database Adapter used in the SOA Suite) and the developers implementing the service contract. Such a contract in terms of nested types quite close resembles the typicall WebService contract that used nested XML documents.
So the first layer of service API can be one in terms of user defined types. However, many potential consumers of the service do not speak ‘Oracle type lingo’. They can deal with strings and numbers and a string may contain a complex block of data when it is constructed as XML, but Oracle Types are beyond them. So we may need a second layer on top of the user defined type service API – a second layer that speaks XML.
Fortunately it is rather simple to turn the XML input to this second layer and convert it to Oracle Object speak (user defined types) and also to take the result from the innner API that is in terms of the user defined types and turn it into [an] XML [message]. The mechanisms we can use for the conversion from UDT (or ADT) to XML and vice versa are XMLType, SYS_XMLGEN and the TOOBJECT operation on XMLType.
Oracle RDBMS 11gR2 – alter or replace user defined types even when there are dependencies
Sep 2nd
In our series on the 11g R2 release of the Oracle RDBMS, AMIS staff discusses various functions, features an facilities that have been added, improved or extended in this latest release. These articles are the fruit of several months of studying this new release and projecting which new features and changes would be the most useful to us in our daily practice. This article looks at apparently relatively minor changes in functionality that may well have a substantial impact on the usability of Abstract Data Types (ADTs) or user defined (object) types.
Using ADTs or user defined types in the Oracle RDBMS is quite often very useful. Much more useful by the way than many developers realize. The integration for example between SQL and PL/SQL can be streamlined using user defined types in conjunction with TABLE and MULTISET or the BULK COLLECT operations. Presenting a service-style interface from PL/SQL packages is also much easier realized using custom type definitions – easier both for the definition of the package’s "service contract", the consumer of the package (at least the Database Adapter used in the SOA Suite) and the developers implementing the service contract. Such a contract in terms of nested types quite close resembles the typicall WebService contract that used nested XML documents.
One less agreeable aspect of types (prior to 11gR2 that is) is their administration. Especially the fact that once a type has been created and has been referenced by other types, it cannot be altered. In order to change a small (or big thing) in a single type, it may be necessary to drop a whole bunch of types that are all somehow related to each other. When the types are all recreated, they can be recreated with the required change inside. Types are much like views or packages: database objects that are owned, have associated privileges and synonyms, and add to the general complexity of database applications.
Note: from the administration perspective, it makes quite a difference whether the types are used only for PL/SQL programs and SQL/PLSQL integration – to define the record structure used for the interaction and to create in memory data structures – or whether the types describe the storage structure for columns or nested tables. In the latter case, changing the type has far more impact than in the previous case – where changing types should not have to have a lot of effect.
In 11gR2, the impact of changing types has been brought to where it really should be: changing a type is allowed even if there are dependencies on that type – as long as those dependencies are not from nested tables/columns. Dependencies from PL/SQL program units or views or other types (that are not used for storage structures) are fine and will allow the change of the type (and even a drop of the type). This ability to modify types without recreating the entire nested structure of inter-dependent types will make use of types in PL/SQL applications much more acceptable to DBAs.
I will show you the scenario that up to 11gR2 would cause the nastiness that has now been resolved in 11gR2:
