Re: testing app

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Mon Jan 27 2003 - 10:31:01 EST

  • Next message: Andriy Shapochka: "Re: Cayenne Operations Sorters"

    Wonder what is the best place for including this code? Will it run with
    the main version of Cayenne or does it have dependencies on your other
    changes?

    I suggest a new "subproject" location modeled after our other subprojects,
    e.g. "cayenne/src/regression", with "java" subfolder underneath.

    If there are dependencies on the missing stuff, we may exclude this
    "subproject" from the main buildfile until this is resolved.

    Andrus

    > Thanks everybody for +1's on my inclusion.
    >
    > Here is a brief description of my testing app (number 3 in Andrei's
    > list):
    >
    > 3) Created the functional Oracle-oriented prototype of the Cayenne
    > testing app dwelling in the package org.objectstyle.cayenne.test. Its
    > purpose is to automatically generate a set of random database schemas
    > and quality of the Cayenne's commit against them. A short description
    > of the steps follows:
    >
    > 1. A random Oracle schema is generated. Table count, max. count of
    > foreign keys a table can have, max count of the tables referencing a
    > table, seed of the randomizer, Oracle database connection, and name of
    > the schema are configured
    >
    > 2. A data map is created for the schema generated and attached to the
    > data node representing the database connection.
    >
    > 3. The data domain having been configured by steps 1. 2., a robot
    > randomly creates and registers data objects for the data map in the
    > data context. It also establishes relationships among them accordingly
    > to the meta data in the data map.
    > (Note: delete/update functionality has recently been added)
    >
    > 4. The modified context is committed to the database.
    >
    > Principles a schema is built on:
    > 1. Schema's name must be the name of the default connected user's
    > schema. 2. Preferably it should be empty in order for newly generated
    > tables and sequences not to interfere with the existing ones.
    > 3. All the tables created have primary keys either autogenerated (for
    > such tables sequences are created) or dependent. Most of the tables
    > have enabled 'NOT NULL' foreign keys. Thus columns of the tables can
    > be primary keys, foreign keys, or both in the case of dependent tables
    > (like many-to-many tables-relations, and such) of the type INTEGER.
    > All of them are 'NOT NULL' and do not have default values.
    > 4. The graph of the referential relations is always acyclic.
    > 5. The produced schema is usually quite complex in the sense of
    > referential integrity and complies with the principles of the theory
    > of relational databases.
    >
    > To start the app one must execute a command line like:
    > java org.objectstyle.cayenne.test.Main path_to_config_file
    > The config file contains parameters to tune the app. For the details see
    > doc/test/schema-test.config. If the command line argument is
    > omitted the app tries to find "./schema-test.config".
    > Several schemas can be created and several commits can be performed per
    > schema during one run of the app. Quite descriptive information along
    > with the create and drop scripts and the data map are stored as files.
    > The important info is outputted to the console as well, so regularly it
    > is advised to run java instead of javaw. Also, it is advised to
    > tune the memory heap of the JVM like java -Xms150m -Xmx150m in case one
    > would like to run intensive tests with lots of tables and data objects.
    >
    > Several hundreds of random schemas of 10, 25, 30, 50, and 100 tables
    > were tested by the app on Oracle 9.2. All the tests succeeded working
    > with the new commit. The old commit failed on the same tests. At the
    > same time Cayenne turned out very stable and easily runtime
    > reconfigurable and did not show any notable memory or database resource
    > (like open cursors) leakages even when it was created 100 schemas, 50
    > tables per schema, 30 data objects per table, 20 commits per schema.
    > Moreover the garbage collector could very effectively clean the memory
    > from the stale data, which was monitored very attentively.
    >
    > Another note - the robot might evolve into a fully functional automatic
    > testing tool for existing schemas to measure and qualify how well a
    > given schema and data map work on various sorts of data manipulation in
    > the extensively loaded environments. Such a tool would be precious in
    > the cases when multi-user web or intranet application performance must
    > be tested as it is known too many serious and hardly identified
    > bottle-necks occur in the communication of an app and database server.



    This archive was generated by hypermail 2.0.0 : Mon Jan 27 2003 - 10:31:02 EST