Release Notes
|
 |
 |
|
 |
 |
The BEA AquaLogic Data Services Platform 2.0.1 now supports WebLogic Platform 8.1 Service Pack 5 (SP5). No upgrade is needed. However, if you are planning on using DSP 2.0.1 with SP5 see release note CR247416 related to interdomain transactions between WebLogic Server 8.1 SP4 and 8.5 SP5.
Data Services Platform (DSP) provides on-demand access to, and aggregation of, information in relational databases, Web services, Java functions, XML files, delimited files, and other types of disparate data. During development, DSP is accessed as an application running under WebLogic Workshop. This is where you develop your data services, including query and relationship functions.
Once developed, application developers — using access technologies such as the Data Services Platform mediator API, JDBC, SQL, or Data Services Platform controls — can invoke DSP query functions as a means of providing their applications with access to integrated, updateable data from their enterprise.
Metadata, security, and cache management facilities are provided through the Data Services Platform Console (ldconsole).
Note: Data Services Platform was formerly named Liquid Data. Some artifacts of the original name remain in the product, path, and components.
These Release Notes are subject to revision between releases. The most recent version can always be found at:
http://download.oracle.com/docs/cd/E13167_01/aldsp/docs20/relnotes/index.html
Items modified or added are so marked by date.
This document includes the following topics:
Data Services Platform 2.0.1 is a service pack release primarily designed to validate product durability and address known issues. This has included:
Table 1 lists known, potentially encountered limitations associated with the current BEA AquaLogic Data Services Platform 2.0.1 release. Information regarding these limitations includes a CR (Change Request) number for each problem, applicable platform, a detailed description of the problem and workarounds, where applicable.
Please contact BEA customer support at http://support.bea.com for assistance in tracking unresolved problems.
Table 1 Known Product Limitations and Workarounds
|
Interdomain transactions between WebLogic Server 8.1 SP4 and 8.1 SP5 require a command line flag to be passed. |
|
|
Running a Web service created for a Data Service control from a remote machine gives the following exception: |
|
|
When using interdomain transactions between 8.1 SP4 and 83.1 SP5 a command-line flag to the 8.1 SP5 domain is needed for DSP if the Data Service control and the calling application are in separate domains with one running 8.1 SP4 and the other 8.1 SP5.
More details on the JTA transaction are available at: http://download.oracle.com/docs/cd/E13222_01/wls/docs81/ConsoleHelp/jta.html#1106135 |
|
|
Currently the Web services wrapper provided by DSP only supports single-dimension arrays in RPC style Web services |
|
|
The initial invocation of a Web service call from the application server typically takes more time than subsequent calls. If the timeout value is less than the time required for the first call, the alternate expression (typically a timeout error) will be evaluated. |
|
|
There is "startup overhead" the first time that a web service is invoked. The overhead can exceed the timeout threshold, leading to the specified timeout error. |
|
|
When setting timeout on expressions that have a Web service invocation, set the timeout value to be greater than the measured amount of time required for the first invocation. |
|
|
The JDBC driver may not support the use of wildcards (i.e., WIRE% for WIRELESS) as a means of identifying database catalogs. The result is that no catalog is found when a wildcard is used to specify an available database catalog. |
|
|
Use the exact name, not wildcards, when specifying a catalog name. |
|
|
XQueries may generate invalid SQL for databases not supporting UPPER and LOWER (SQL-92). |
|
|
There are two aspects to this problem: 1. XQueries containing upper-case() or lower-case() functions are pushed down for database processing as UPPER and LOWER. Some databases may not support these SQL-92 keywords, however. In such cases the generated SQL will be invalid and will upon execution fail. 2. Similarly, input handling by base databases (as well as Oracle databases) may not match the XQuery specification. The reason for this is that while the XQuery specification requires that functions return an empty string if input is an empty sequence. However, when these functions are pushed down, they return an empty sequence instead. This happens because LOWER(NULL) is NULL in SQL. |
|
|
Use the fn-bea:Fence() function to prevent pushdown of upper-case() or lower-case() functions to the database. Example: |
|
|
SDO update does not preserve the sequence of update objects; instead it updates in alphabetical order (example: address, credit card, customer). Since the insertion order is automatic, the update will fail unless the update elements match alphabetical order. |
|
|
If the dependency order matches alphabetical order, the update will be successful. |
|
|
Metadata search using the `?' wildcard may not return expected results. |
|
|
In metadata browser search the "?" wildcard should match with exactly one valid character of any value. However, the "?" wildcard actually matches any exact number of characters or a subset. For example, searching for "CUSTOMER_???" will match both "CUSTOMER_ABC" and "COSTUMER_AB". While this is in keeping with certain Java wildcard behavior, it is inconsistent with standard Windows search behavior. |
|
|
An exception appears for XQuery functions accessing metadata derived from Microsoft SQL Server stored procedures containing xs:decimal. |
|
|
When importing a stored procedure from Microsoft SQL Server, the BEA JDBC driver incorrectly maps SQL decimal type to schema integer (xs:int) type. |
|
|
During stored procedure import, change the data type from xs:int to xs:decimal. Alternatively, you can change the imported data service's metadata to specify the schema type for the affected column to be xs:decimal. |
|
|
ROWTYPE input cursor is not supported when creating a data service from a stored procedure. |
|
|
Stored procedure IN and INOUT cursors containing ROWIDs are not currently supported for metadata import. |
|
|
Avoid importing metadata on stored procedures which required use of IN or INOUT ROWID parameters. |
|
|
The query engine cannot retrieve data from a Sybase data source when the generated SQL contains functions which have dependencies on Java services. |
|
|
When using Sybase relational data as a data source, some SQL functions such as LTRIM and RTRIM work correctly in the database only when Java services are enabled by running the following in the SA role. |
|
|
Enable Java services while in the SA role. Refer to Sybase documentation for details. |
|
|
The XQuery 1.0 processing-instruction() node test is not fully supported in the BEA XQuery processor. |
|
|
Using processing-instruction("name") ignores the "name" and instead retrieves all processing-instruction nodes. |
|
|
A limitation of the WebLogic web services stack interferes with the ability to handle WSDL files with multiple data services. |
|
|
Erroneous results may occur when using fn:matches() with a regular expression containing a caret (^). |
|
|
The match beginning-of-line operator (^) in regular expressions produces erroneous results when used with |
|
|
Identifiers within two characters of the maximum length allowed by the database may result in an error. |
|
|
Some databases place limits on the length of identifiers (30 in the case of Sybase). Data Services Platform places single quotes around pushdown queries, effectively reducing the maximum identifier length by two characters (28 in the case of Sybase). |
|
|
All platforms running Sybase (and possibly other) databases. |
|
|
Possible options include renaming the table or creating a view with a shorter name. |
|
|
Some data sources may not appear when attempting to import metadata. |
|
|
The functionality to manage JDBC data sources and connection pools during metadata import is limited to the same level of functionality provided by BEA Workshop (Tools |
|
|
For full functionality use the WebLogic Administration Console to manage JDBC data sources and connection pools. |
|
|
This version of Data Services Platform cannot invoke SOAP 1.2 based Web services. |
|
|
Linux application built in Workshop may fail with the message "Error creating temporary file". |
|
|
While building an application inside Workshop on Linux, you may get the above error when 1) the application includes a large number of schema files, and 2) when the Platform Installation is under a different user's name than the user running Workshop. |
|
|
Ensure that the Workshop instance is running under the same name as was used for Platform installation. |
|
|
Access control policies associated with a data service function may disappear if the function's number of parameters is changed. |
|
|
A data service function's signature is it's QName and the number of parameters (arity) of the function. If you set security policies on a function and changes the number of parameters to the function, then this function is treated as a new function and the previously set policies will no longer be in effect. |
|
|
If a functions arity is changed, the user will have to reapply security policies to that function. |
|
|
The BEA JDBC XA driver for DB2 returns the error XAER_RMERR when a local transaction read is followed by a global transaction read. |
|
|
Pertains to a known JDBC driver problem described in BEA CR229071. |
|
|
Data Services Platform Web service generation may fail to compile if the original Web service was created in Workshop. |
|
|
If you have a data service created from a Workshop-originated Web service and then, subsequently, you turn your data service into a web service via a Data Services Platform control, the project build will fail due to a duplicate schema element error. |
|
|
Assume that you have a Workshop-generated Web service named getCustomerOrderByCustomerID. A WSDL for this Web service with default targetnamespace would create the following schema elements:
When you import this WSDL, the same schema elements will be in the imported schema file and will be associated with the data service read function. When you build a Data Service control for this read function and generate a Web service from that control, a Web service function is created:
When compiling this Web service file, now workshop generates two identical schema elements each for {http://www.openuri.org/}getCustomerOrderByCustomerID and {http://www.openuri.org/}getCustomerOrderByCustomerIDResponse. Thus create the schema element clash. If user had modified either the target namespace of this final JWS or changed the function name to a different one like this: org.openuri.GetCustomerOrderByCustomerIDResponseDocument getCustomerOrderByCustomerIDNEW(org.openuri.GetCustomerOrderByCustomerIDDocument p0) Then the types generated will be as follows and there will be no clash. {http://www.openuri.org/}getCustomerOrderByCustomerID and {http://www.openuri.org/}getCustomerOrderByCustomerIDResponse {http://www.openuri.org/}getCustomerOrderByCustomerIDNEW and {http://www.openuri.org/}getCustomerOrderByCustomerIDNEWResponse Thus the schema clash will be avoided. When compiling this WebService file, now workshop generates two identical schema elements each for {http://www.openuri.org/}getCustomerOrderByCustomerID and {http://www.openuri.org/}getCustomerOrderByCustomerIDResponse. Thus create the schema element clash. If user had modified either the target namespace of this final JWS or changed the function name to a different one like this: org.openuri.GetCustomerOrderByCustomerIDResponseDocument getCustomerOrderByCustomerIDNEW(org.openuri.GetCustomerOrderByCustomerIDDocument p0) Then the types generated will be as follows and there will be no clash. {http://www.openuri.org/}getCustomerOrderByCustomerID and {http://www.openuri.org/}getCustomerOrderByCustomerIDResponse {http://www.openuri.org/}getCustomerOrderByCustomerIDNEW and {http://www.openuri.org/}getCustomerOrderByCustomerIDNEWResponse |
|
|
When compiling this Web service file, Workshop now generates two identical schema elements each for:
Thus the schema elements clash. If you modify either the target namespace of the final JWS or change the function name to a different one such as:
Then the types generated will be as follows and there will be no clash. |
|
|
|
|
|
BEA Informix JDBC driver does not return nullability information. |
|
|
The BEA Informix driver does not return information about table column nullability (that is, it is marked as unknown). Thus during metadata import the minOccurs of the elements corresponding to the columns in the generated XML schemas is set to 0. |
|
|
Modify the imported metadata files by changing the minoccurs value for the nullable columns from 0 to 1. |
|
|
There are two limitations with this MSSQL VARIANT data type (sql_variant): |
|
|
During metadata import, tables with multibyte names may create multibyte namespace prefixes based on the table name's first few characters. The resulting data service file will not be parsed correctly because the XMLBeans parser is unable to handle multibyte namespace prefix value. |
|
|
In Source View syntax highlighting may become off by a character if certain sequences appear in the query. |
|
|
Data Services Platform IDE Test View is limited to a flat structure when performing a SDO update. |
|
|
Through Data Services Platform Test View Data you can accomplish typical read and update actions. For example, you can create new SDO records as part of update steps. However, when adding a new SDO record that has a nested structure, the template generated will only have first-level (i.e., no nested) elements. |
|
|
You can add subsequent nested SDO records by right-mouse clicking on the container node. |
|
|
During metadata import the BEA Sybase JDBC driver may not display all tables to which user has authorized access. |
|
|
During metadata import the BEA Sybase JDBC driver may not show all tables which have been granted access to the user. |
|
|
All platforms accessing Sybase through the BEA Sybase JDBC driver. |
|
|
This is a BEA Sybase driver limitation. For the import purpose, you can change to |
|
|
Repeated builds of a Workshop application containing one or more Web service projects can run out of memory. |
|
|
If you have a Workshop application that has a large number of Web service files ( |
|
|
Obtain and apply the Workshop patch associated with CR226814. This patch corrects the memory leak problem described above. |
|
|
When using BEA Oracle JDBC driver with a TIMESTAMP values, stored procedures are truncated. |
|
|
When using the BEA's Oracle JDBC driver, if a stored procedure returns a TIMESTAMP value then the value gets truncated at the milliseconds level. For example, if the value was 1997-01-31 09:26:50.124 then the stored procedure will return a 1997-01-31 09:26:50.0 value. |
|
|
All platforms running Oracle with the BEA Oracle JDBC driver. |
|
|
Use the Oracle JDBC driver stored procedures that returning TIMESTAMP values. |
|
|
The Data Services Platform cache configuration does not work if using Sybase JDBC driver because the configuration implementation uses a getBlob() call on the JDBC driver. The Sybase JDBC driver does not support getBlob(). |
|
|
Use the BEA JDBC driver for Sybase databases when utilizing Sybase as the Data Services Platform cache data source. |
|
|
SQL Server JDBC driver incorrectly renders the tinyint maximum value. |
|
|
The SQL Server tinyint maximum value of 255 gets interpreted as -1 by the Microsoft SQL Server JDBC driver. |
|
|
All platforms running SQL Server with the SQL Server JDBC driver. |
|
|
The Informix JDBC driver does not support standard JDBC syntax for specifying TIMESTAMP values. |
|
|
The Informix native driver doesn't support standard JDBC syntax for specifying TIMESTAMP values. For example: 1979-03-01 00:00:00.0 is not supported. |
|
|
All platforms running Informix with the Informix JDBC driver. |
|
|
The BEA JDBC driver for Oracle does not support UROWID column type for data retrieval. |
|
|
When using BEA JDBC driver for Oracle, retrieving UROWID returns an error, identified by the following message:
|
|
|
Use the Oracle JDBC driver if your data contains UROWID column type. |
|
|
The Oracle stored procedure returning PL/SQL RECORD, BOOLEAN, or table with non-scalar element types is not supported. |
|
|
Oracle stored procedure limitations are detailed in the following currently-available document: http://www.stanford.edu/dept/itss/docs/oracle/9i/java.920/a96654/ref.htm#1007714 |
|
|
Metadata for SQL Server stored procedures returning CURSOR output cannot be created. |
|
|
When importing metadata from SQL Server, stored procedures that return CURSOR output are not supported. |
|
|
Modify the imported data service file to the identify the correct data type for the cursor. |
|
|
Metadata for DB2 stored procedures returning CLOB data cannot be created. |
|
|
When importing metadata from DB2, stored procedures returning CLOB data are not supported. |
|
|
Oracle stored procedures containing CHAR or NCHAR as input can cause a Server error. |
|
|
If you have Oracle stored procedures that use an INOUT parameter, you may get an error when you run a stored procedure using Data Services Platform. The error appears as:
|
|
|
Modify your stored procedure call by reducing the size of the INOUT parameter using TRIM. See Listing 1, below. |
Listing 1 Sample code related to CR202962
CREATE OR REPLACE PROCEDURE WIRELESS.SP_CHAR
(P_CHAR_IN IN CHAR,
P_CHAR_OUT OUT CHAR,
P_CHAR_INOUT IN OUT CHAR,
P_ID_OUT OUT VARCHAR2 )
IS
TEMP VARCHAR2(10);
BEGIN
SELECT C_ID INTO P_ID_OUT
FROM WIRELESS.ALL_DATATYPES
WHERE C_CHAR = P_CHAR_IN;
SELECT C_CHAR INTO P_CHAR_OUT
FROM WIRELESS.ALL_DATATYPES
WHERE C_ID = '2';
SELECT C_ID INTO TEMP
FROM WIRELESS.ALL_DATATYPES
WHERE C_CHAR = P_CHAR_INOUT;
SELECT 'WORK' INTO P_CHAR_INOUT
FROM WIRELESS.ALL_DATATYPES
WHERE C_ID = TEMP;
END;
/
to adjust the size of PCHAR_INOUT using TRIM (see highlighted code)
CREATE OR REPLACE PROCEDURE WIRELESS.SP_CHAR
(P_CHAR_IN IN CHAR,
P_CHAR_OUT OUT CHAR,
P_CHAR_INOUT IN OUT CHAR,
P_ID_OUT OUT VARCHAR2 )
IS
TEMP VARCHAR2(10);
ACHAR CHAR(500);
BEGIN
ACHAR := trim(P_CHAR_INOUT);
SELECT C_ID INTO P_ID_OUT
FROM WIRELESS.ALL_DATATYPES
WHERE C_CHAR = P_CHAR_IN;
SELECT C_CHAR INTO P_CHAR_OUT
FROM WIRELESS.ALL_DATATYPES
WHERE C_ID = '2';
SELECT C_ID INTO TEMP
FROM WIRELESS.ALL_DATATYPES
WHERE C_CHAR = ACHAR; // used to fail here
SELECT 'WORK' INTO P_CHAR_INOUT
FROM WIRELESS.ALL_DATATYPES
WHERE C_ID = TEMP;
END;
/
Documentation for this product is available on an Online Documentation CD-ROM that ships with the product, and is also available on the Web at the BEA e-docs documentation site at the following location:
http://download.oracle.com/docs/cd/E13167_01/aldsp/docs20/index.html
To access the Data Services Platform documentation home page in a Web browser:
Alternatively, from within a HTML document, click the View as PDF link on the top navigation bar to open a PDF version of the currently displayed document.
Information about BEA products including Data Services Platform can be found at:
http:dev2dev.bea.com
Documentation for all BEA products in both PDF and HTML format can be found at:
http://www.oracle.com/technology/documentation/index.html
If you do not have Adobe Acrobat Reader, you can obtain it from the Adobe Web site at:
http://www.adobe.com
|
|
|