Jena2 Database Interface - Open Issues
2 November, 2004
Open Issues
- Persistent Model Interface
- There are three different mechanisms for creating persistent models. Users
are encouraged to use the factory methods for creating models (ModelMaker and
ModelSpec). However, this is a new mechanism that does not yet support all the
required functionality for persistent models. The ModelRDB class has methods
for constructing Jena2 persistent models. It also has Jena1-compatible methods
for creating persistent models. These ModelRDB methods are deprecated but may
still be needed by applications until the ModelMaker mechanism is fully
functional.
-
- Namespace Prefix vs. URI Compression
- Jena2 provides persistence for namespace abbreviations. However, this
mechanism is separate from the URI compression scheme. This means that the
same URI prefix (namespace) may be stored in two different places or a URI may
be encoded in two different ways. It might be convenient if a common mechanism
were used so that URI compression might reuse existing namespace
abbreviations. It is unclear if there is a significant performance impact.
-
- Fastpath Testing
- If problems are found or suspected in RDQL query processing over the
database, the Fastpath code can be disabled and Jena will revert to a simpler,
less-efficient mode of query processing. See Fastpath for
details on doing this.
-
Known Bugs
- Plain Literals vs. XSD String-typed Literals
- The RDF recommendation states that if an XSD string-typed literal and a
plain literal (no language tag) have the same value (see Literal.getValue()),
then they are considered semantically equivalent, i.e., Literal.sameValueAs()
returns true. Unfortunately,
the database layer does not treat them as equivalent. For example, if a
statement with an xsd string-typed literal for an object is added to a database
model, then in a subsequent attempt to list all statements with that value as
a plain literal, the original
statement (with the typed literal) will not be included in the result set.
- Database Lock
- The Jena2 storage subsystem uses a lock (or mutex) internally to implement a
critical section for operations that modify the database structure
(create/delete tables). The lock is implemented as a database table, i.e., if
the table exists in the database, the lock is held. Normally, this lock
should be transparent to applications. But if an application has an exception
while in a critical section, the database may remain locked for subsequent
applications. In this case, a user must manually unlock the database either by
calling DriverRDB.unlockDB() or by deleting the table (Jena_Mutex) from the database.
There are many unknown bugs. Unfortunately, we have not had time to do as
much testing as we would have liked. Please do not hesitate to contact us on
the jena-dev or jena-devel lists when you suspect a problem.