[jira] Closed: (DERBY-1987) Add Order Entry application/system/performance test/toolkit

["Rick Hillegas (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Hillegas closed DERBY-1987.
--------------------------------

    Resolution: Fixed

It seems that the work for this issue has been done.

> Add Order Entry application/system/performance test/toolkit
> -----------------------------------------------------------
>
>                 Key: DERBY-1987
>                 URL: https://issues.apache.org/jira/browse/DERBY-1987
>             Project: Derby
>          Issue Type: Improvement
>          Components: Test
>            Reporter: Daniel John Debrunner
>            Priority: Minor
>
> Order Entry (OE) is an OLTP application/toolkit which is based upon the TPC-C specification,
> but is not claiming to be a valid implementation. The TPC-C specification is used mainly for
> the database schema & population rules and the logic of the business transactions.
> http://www.tpc.org/tpcc/
> OE is set up so that the driving & display of the business transactions is separated from the actual implementation,
> which then allows different implementations to compare performance of Derby features. In all cases the implementations
> would perform the logical functionality required by the TPC-C, but need not be strict implementations. As an example
> the new order number is obtained in a defined way in TPC-C, but Derby could use generated keys to perform the
> same logical function. Testing the two ways would lead to see if there were performance problems with generated keys.
> Examples of the possible implementations of the business transactions are:
>     - direct - client executes SQL statements directly holding onto PreparedStatements for the lifetime of the client)
>     - procedure - client executes a procedure per business transaction
>     - EOD - implementation using JDBC 4^H5? EOD
>     - updateable ResultSets
>     - positioned updates
>     - etc.
>     
> Other options include
>      - use of triggers
>      - use of generated keys
>      - etc.
> Possible values for the display (results of the transaction)
>    - nothing
>    - text
>    - HTML for servlets/JSPs
>    - etc.
> Also the loading of the data could support different options:
>    - load with/without contraints in place
>    - load using INSERT statements
>    - load using import 
>    - load using import with a ResultSet class.
> OE allows the amount of data loaded initially to be varied very easily, just by setting the warehouse
> scale factor, so a warehouse=1 creates a database of size N, and warehouse=100 a database of size 100N (roughly).
> This allows databases in the range 10-100Gb to be easily created.
> The general setup would that OE could be used as a function test, performance test, or stress test,
> so it's seen as a toolkit.
> I hope also that the OE could be expanded beyond the TPC-C spec, for example:
>   - adding images (BLOBs) and descriptions  (CLOBs) to the product ITEM table.
>   - adding triggers to send-email on various actions.
> These additions would be intended to test Derby functionality in a "real-world" OLTP application.
> The top-level package under java/testing would be
>    org.apache.derbyTesting.systemTests.oe

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.