incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Promoting TxTDB to TDB/trunk
Date Mon, 10 Oct 2011 08:33:14 GMT
Paolo, all,

I think it's time to promote TxTDB to be the TDB trunk.

The criterion I have is whether TxTDB provides at least the same 
functionality as TDB.  That is, when running non-transactionally, is 
TxTDB good enough to be the next TDB?

There are some missing features for transactions:

   Dataset level API [*]

and a 1001 other things that could be done.

Triage the JIRA list:

JENA-133     provide configurability of cache sizes
   Not critical for a release - adds something that isn't there now.

JENA-131     TxTDB problem during concurrent execution
   Insuffcient evidence currently.
   Not critical for the switchover - does not break TDB in non-txn mode.

JENA-117     A pure Java version of tdbloader2
   Not critical for a release - adds something that isn't there now.

JENA-106     Merge joins in TDB
   Not critical for a release - adds something that isn't there now.
   Need performance framework to determine when/if it
   makes a positive difference.

JENA-97     TDB 0.9.0 snapshot sometimes returns a SELECT binding twice
   Awaiting confirmation.  Test case does not illustrate the problem.
   Not new to TxTDB.
   A possible alternative reading of the report has been fixed.

so I propose doing a switch over by:

svn mv \

svn cp \

The only reason for the second being a "cp" (I strongly prefer not 
leaving visible orphan copies around) is to have a temporary version 
that marks the changeover.  By diff'ing TDB/trunk against 
Experimental/TxTDB/trunk, it would be possible to find items to backport 
to TDB-0.8.X should that be necessary.  I expect the copy to be around 
for a short period of time only.

Whether "svn up" can cope I don't know - it may mean a clear checkup is 
needed but that might be safer anyway.

Then an important looking JIRA item for TDB is:

JENA-102     tdbloader creates stats.opt file in existing DB
   Not a blocker because it's problem with the current release.
   It is well worth addressing stats.opt maintenance properly,
   not just solving the point problem.


[*] As in "finish" and "decide which of two ... or both options"

View raw message