As developers use the persistence layer of the WAF, several types of errors are made by many developers. This document tries to highlight some of those errors to help with debugging tasks. Another document that may be of interest to developers having problems with persistence is the Section 9.10 Frequently Asked Questions.
One of the most common and most easily fixed errors is that of an invalid character. The error is typically something such as:
com.arsdigita.persistence.PersistenceException: ORA-00911: invalid character |
This error is caused because the developer accidentally included a semi-colon at the end of a SQL statement. For instance, the following retrieve event will cause the above error because of the semi-colon (in bold) at the end:
retrieve {
do {
select publication_id, name
from publications
where publication_id = :id;
} map {
id = publications.publication_id;
name = publications.name;
}
} |
To fix the error, simply remove the semi-colon so that the event definition appears as follows:
retrieve {
do {
select publication_id, name
from publications
where publication_id = :id
} map {
id = publications.publication_id;
name = publications.name;
}
} |
This error occurs is because the query is fed directly to the database using the JDBC driver, which does not exptect a trailing semi-colon.
When you receive an error indicating that an attribute cannot be found or an attribute name is invalid, make sure that there are no typos. Simple typos cannot be caught by the compiler and cause many errors.
Typically, two types of mistakes occur when dealing with Transactions within the WAF.
The first type of mistake is trying to access Data Objects (and hence the database) outside of a transaction. This typically happens when the developer tries to write a custom dispatcher that bypasses the standard WAF dispatcher and does not remember to include transaction management. To fix this, make sure that the custom dispatcher properly opens and closes transactions using appropriate WAF APIs.
The second type of mistake is the exact opposite of the first: trying to nest transactions. Unless you have written a custom dispatcher that bypasses the standard WAF dispatcher, you should never have to open or close a transaction. Trying to do so within the standard framework of the WAF will result in an error. In almost all cases, developers building on top of the WAF should not try to manage their own transactions.
For more information, see the document on Section 9.7 Transaction Management.
Common problems:
Non-continuous join paths -- the second column's table in each join path element must match the table of the next join path element's first column. That is, the path must look somthing like join A.B to C.D, join C.E to E.F In this example, table C is the last table of the first half and the first table of the second half.
Join paths are too long -- MDSQL only supports join paths composed of 1 or 2 join path elements. If paths are longer than that, it becomes impossible to generate events correctly given the current implementation.
Join path does not start in the primary table -- a join path must always start in the same table as the reference key or object key. If it does not, there is a gap and the event cannot be generated.
Dyanmic DDL Generation works well when the PDL is specified correctly. However, it is easy to think that the PDL is written to represent the model correctly when in fact you are missing a simple item to two. Below are some symptoms that you may see with your generated DDL and some suggestions as to how you may be able to fix them.
| Data Model Problem | Likely Cause in PDL |
|---|---|
| Missing columns | Properties were specified without a column or join path |
| Missing foreign keys | Object Model doesn't use associations, but data model does, e.g. Message object has BigDecimal authorID property instead of User author property, in these cases an easy fix is to create the author association without removing the authorID attribute so that existing java code continues to work. |
| Missing not null | The property in PDL is [0..1] when it should be [1..1]. |
| Extra not null | The property in PDL is [1..1] when it should be [0..1]. |
| Missing on delete cascade | The property in PDL should be declare component or composite. |
| Missing unique constraint | The property(ies) in PDL should be declared unique. |
When developing code using persistence, you may have a difficult time tracking down the reason for a PersistenceException. Turning up the logging level can help you understand what is going on. The following Log4J loggers com.redhat.persistence.Session and com.redhat.persistence.engine.rdbms can be turned to the info log level to help see what is going on. The latter will log all SQL being sent to the database.