Returning a Single Result Set TopLink Joined-Attribute Reading

Oracle JCA Adapter for Database 9-51 Configuration To configure, select Use Outer Joins to return a Single Result Set for both Master and Detail Tables on the Adapter Configuration Wizard - Define Selection Criteria page.

9.4.1.3.4 Comparison of the Methods Used for Querying over Multiple Tables

On the surface, returning a single result set looks best 1 query, followed by batch attribute reading altering the select statement: 2 queries, and finally by default relationship reading n + 1 queries. However, there are several pitfalls to both of the more advanced options, as explained below: Altering User-Defined SQL If you specify customhybrid SQL, the TopLink cannot alter that SQL string to build the details select. For this reason, you must avoid using hybrid SQL and build selects using the wizards visual expression builder as often as possible. Show Me the SQL The additional queries executed by TopLink in both, the default and the batch attribute reading cases can be somewhat of a mystery to users. For this reason, the raw SQL shown to users in the Adapter Configuration Wizard assumes returning a single result set, to make things clearer and also to improve manageability. Note: When you create a SQL query such as the following by using the TopLink Expression Builder, the result may not be as expected: SELECT DISTINCT t1.TABLE1_ID, t1.COLUMN_A FROM TABLE2 t0, TABLE1 t1 WHERE t0.STATUS = 1 AND t0.TABLE1_ID = t1.TABLE1_ID The expected result for this query is that only rows with Table 1s and their owned Table 2s with status = 1 be returned. However, what this query actually translates to is table 1s, where any of its table 2s have status = 1, resulting in the return of table 1s that match the selection criteria, and ALL of the table 2s they own, including those with other statuses, whether or not their statuses =1. The DISTINCT keyword ensures the table 1s are not repeated and the join happens across table 2. The misunderstanding happens in the way Toplink works. Through the Expression Builder, you can only specify a selection criteria for Table 1 and have no control over the Table 2s they own, this part is automatically done. However, you can get the expected result by using either of the following two approaches: 1. Query directly for table 2 using the selection criteria of status = 1, that is, do not go through table 1 and get the table 2s they own. 2. Use direct custom SQL, as shown in the following example: SELECT TABLE1.TABLE1_ID, TABLE1.COLUMN_A, TABLE2.STATUS FROM TABLE2, TABLE1 WHERE TABLE2.STATUS=1 AND TABLE1.TABLE1_ID = TABLE2.TABLE1_ID 9-52 Oracle Fusion Middleware Users Guide for Technology Adapters Returning Too Many Rows At Once Databases can store vast quantities of information, and a common pitfall of select statements which return too much information at once. On a DBAdapter receive, a maxTransactionSize property can be set to limit the number of rows which are read from a cursored result set and processed in memory at a time. A similar max-rows setting exists for one time invoke select statements. However, this setting is very risky.

9.4.2 SQL Operations as Web Services

After mapping a relational schema as XML, you must also map basic SQL operations as Web services. Each operation discussed in the following sections has a corresponding tutorial and a readme file. It is recommended that you start with these and try to run one or more as you read this section. As the tutorials demonstrate, some operations translate directly to the SQL equivalent, while others are more complex. This section includes the following topics: ■ Section 9.4.2.1, DML Operations ■ Section 9.4.2.2, Polling Strategies

9.4.2.1 DML Operations

Data manipulation language DML operations align with basic SQL INSERT, UPDATE, and SELECT operations. SQL INSERT, UPDATE, DELETE, and SELECT are all mapped to Web service operations of the same name. The MERGE is either an INSERT or UPDATE, based on the results of an existence check. A distinction is made between the data manipulation operations—called outbound writes—and the SELECT operations—called outbound reads. The connection between the Web service and the SQL for merge the default for outbound write and queryByExample are not as obvious as for basic SQL INSERT, UPDATE, and SELECT. This section includes the following topics: ■ Merge ■ querybyExample ■ Use Cases for Outbound Invoke Operations Merge Merge first reads the corresponding records in the database, calculates any changes, and then performs a minimal update. INSERT, UPDATE, and MERGE make the most sense when you are thinking about a single row and a single table. However, your XML can contain complex types and map to multiple rows on multiple tables. Imagine a DEPT with many EMPS, each with an ADDRESS. In this case, you must calculate which of possibly many rows have changed and which to insert, update, or delete. If a particular row did not change or only one field changed, then the DML calls is minimal. querybyExample Unlike the SELECT operation, queryByExample does not require a selection criteria to be specified at design time. Instead, for each invoke, a selection criteria is inferred from an exemplary input XML record. For instance, if the output xmlRecord is an employee record, and the input is a sample xmlRecord with lastName = Smith, then on execution, all employees with a last name of Smith are returned. Oracle JCA Adapter for Database 9-53 A subset of queryByExample is to query by primary key, which can be implemented by passing in sample XML records where only the primary key attributes are set. Use queryByExample when you do not want to create a query using the visual query builder and want the flexibility of allowing the input record to share the same XML schema as the output records. The queryByExample operation is slightly less performant because a new SELECT must be prepared for each execution. This is because the attributes that are set in the example XML record can vary each time, and therefore the selection criteria vary. Input xmlRecord: Employee id lastNameSmithlastName Employee Output xmlRecord: EmployeeCollection Employee id5id lastNameSmithlastName .... Employee Employee id456id lastNameSmithlastName .... Employee EmployeeCollection Use Cases for Outbound Invoke Operations Outbound invoke operations are demonstrated in the following tutorial files: ■ Insert ■ Update ■ Delete ■ Merge ■ SelectAll ■ SelectAllByTitle ■ PureSQLSelect ■ QueryByExample To obtain these files, access the Oracle SOA Sample Code site, and select the Adapters tab. Use Cases for Pure SQL A new option in 10.1.3.1 enables you to specify any arbitrary SQL string, and an XML representing the inputs and outputs to the SQL is generated. Pure SQL operations are demonstrated in the following tutorial files: ■ UpdateAll ■ SelectCount