Troubleshooting the Zero Resource Model
Contents
Known Issues
The following are known issues and are being tracked.
Cannot find Derby database
Although extremely convenient, consideration must be taken when using Derby and
relative databaseName values.
When using Derby (both in embedded and network modes), the databaseName
data source property can be either an absolute or relative path. When it is
a relative path the database to be used is found relative to the owning Java
process. In embedded mode, the owning process is your application. In network
mode, you must explicitly start a Java process (usually through a script).
The default Zero Resource Model database is embedded Derby and uses the relative
path db/resource. CLI tasks can be invoked from anywhere within the app;
however because default ZRM configuration uses relative paths to the current
workign directly instead of the app root, users must invoke ZRM CLI tasks from
the app root at present. Another workaround is to use fixed or absolute paths
for the databaseName.
This can be especially confusing when the Derby data source property is set to automatically create a database if it does not exist. Executing a CLI task from one directory will use one database (relative to the directory) and then switching to another directory will create yet another database.
This issue is being tracked by bug 5092.
Grid is not saving data
Dojo's grid, which zero.grid.DataGrid is based on, requires an edited
cell to loose focus before the changed value is affected in a Dojo Data
implementation like zero.resource.DataStore. Otherwise, if the save
action is performed on the DataStore while editing a cell, the data sent
to the ZRM server will not contain the changes for that cell.
In order to do loose focus and save the edit value of a cell, simply press "Enter" or "Tab" or click away from the cell to loose focus of the cell.
This issue is being tracked by bug 5093.
Fields are not editable in the Grid
Some field types are not editable in the DataGrid. These include the following:
- boolean
This issue is being tracked by bug 4657.
Updated timestamp value changes when loading data
The dumpdata CLI task dumps data from the ZRM database to a JSON formatted
file. This includes a timestamp of the last time each member was updated. The
loaddata CLI task, however, does not respect the value in the JSON formatted
files. Thus, the value that existed in the database prior to the dumpdata
will not be the same value after the loaddata.
This issue is being tracked by bug 4885.
Troubleshooting and workarounds
Reusing zero.data instances
The Zero Resource Model is built on the zero.data module whose database
connection management, by default, will open and close a connection for every
interaction with the database. The zero.data module can override this
behavior by passing in an already opened java.sql.Connection or an instance
of zero.data.groovy.Manager.
For the following examples, the dbKey is configured at
/config/resource/dbKey.
Connection
When obtaining your own connections, it is your responsibility to open and close the connections your application uses.
To achieve similar functionality, the Zero Resource Model looks for a
Connection in the request zone at /request/db/{dbKey}/connection. If
a Connection instance is there, a Manager will be created using it:
// setup connection for reuse
def connection = MyCustomConnectionFactory.getConnection()
request.db.mydb.connection = connection
...
// get a handle on collection, it will reuse the above connection
def collection = TypeCollection.retrieve('person')
def allPersons = collection.list()
...
connection.close()
Manager
Similarly, you can configure the Zero Resource Model to reuse Manager instances.
This is done similarly to connection reuse by placing an instance at
/request/db/{dbKey}/manager:
// setup manager for reuse
def manager = Manager.create('mydb')
request.db.mydb.manager = manager
...
// get a handle on collection, it will reuse the above connection
def collection = TypeCollection.retrieve('person')
def allPersons = collection.list()
You can also control whether the Zero Resource Model will cache the first
created Manager for the duration of the request. By default
/config/resource/cache-manager is true. You can set it to false in your
application's zero.config file:
/config/resource/cache-manager = false
