User's Manual

Chapter 9. Persistence Tutorial 97
3. Generates the events for storing information in the schema in memory so that the ObjectType
returned can be used within DataObjects.
4. Executes the DDL to create the schema. Unfortunately, this causes the system to commit the
current transaction, so it is important that you do not do anything else in the same transaction as
saving the DynamicObjectType.
5. Assuming the DDL executed successfully, saves the PDL that was generated to a table within
the database. The information in this table is then read in on every server startup, so that the
DynamicObjectTypes essentially become permanent.
6. Regenerates events for any children of this object type that may have been affected by any
changes that were made.
9.9.2. Dynamic Associations
The DynamicObjectType supports creating new object types. However, it does not allow the dynamic
creation of associations that involve static object types. Specifically, if a developer wanted to dynam-
ically create an association between Users and the Publications that they read, the only way to do that
would be to add that information to the PDL file, recompile and restart the server. To address this
problem, the system provides a DynamicAssociation class.
This class saves information about the association following approximately the same steps as the Dy-
namicObjectType. The main difference between the classes, besides the types of events they generate,
is that the DynamicAssociation can be used to map two dynamically defined Object Types, two stati-
cally defined Object Types, or one dynamically defined Object Type and one statically defined Object
Type. This is in contrast to the DynamicObjectType that only deals with dynamically defined Object
Types.
9.10. Frequently Asked Questions
This document contains a list of the most frequently asked questions concerning the WAF persistence
layer. For terminology and definitions, please see the Persistence Glossary.
1. General Questions
1.1. Why does the Red Hat WAF have a persistence layer? Why doesn’t it just create the SQL
when and where it is needed?
A persistence layer has been developed as part of the WAF for the purpose of encapsulating
database access routines. This is desirable for at least two reasons: abstraction and database
independence. By encompassing the SQL statements in Java objects, the database access rou-
tines are developed in a scalable environment. Also, the applications are isolated from the
schema changes (which may occur in future versions) since the database access routines are
encapsulated by a standard API. The second reason, database independece, is desirable be-
cause it means that the Java code can easily be ported from one database to another by chang-
ing a small set of centrally located files (as opposed to modifying every file that interacts with
the database).
1.2. Why does the Red Hat WAF have a persistence layer instead of just using standard EJB?
Why is Red Hat reinventing the wheel?
WAF is primarily a framework for building web applications, and Red Hat’s reasoning for
its current architectural direction is best summarized by Sun’s own J2EE Blueprints at
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html.