[
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.
