On Sat, Jul 30, 2016 at 2:56 AM, <[email protected]> wrote: > On Friday, July 29, 2016 01:27:47 PM Bert Massop wrote: > > On Fri, Jul 29, 2016 at 3:43 AM, <[email protected]> wrote: > > > I did the following procedure (with build0018): > > > 1. Comment out all index creation code in getNewDatabaseConfiguration() > > > 2. Start WoT to create a fresh database without any indexes, create an > own > > > identity, stop it. > > > > This assumes that class indexes are off by default. AFAIK by default they > > are on. If my assumptions are right, this can be triggered by explicitly > > disabling the class index for the Configuration class, creating a > database, > > re-enabling indexes, and then querying for Configuration in read-only > mode. > > Ohh good, you made me realize: I was thinking about *field* indexes, not > class indexes. > > But: > When I added the "IndexedClass" annotation which can make the code > enable/disable indexes for each class, I also added "classHasIndex = true;" > to always bypass it and enable the class indexes for *all* classes (with a > TODO to test whether disabling class indexes doesn't break anything). > This means the indexes have been enabled for all classes since then. And > the > code has a comment which says that this also is the db4o default, so it > shouldn't have changed the behavior at all. And that was in 2010 before the > first official WoT release! > > So for what you just described to happen in the wild, the following things > would be required: > 1) The user was using a 2010 database from before I added the code. > 2) db4o actually disables class indexes by default as opposed to its > documentation. > > Rather unlikely, isn't it? >
Rather unlikely indeed. > And besides: Your suggested procedure does indeed cause it to throw, but > with > a different stack trace :| See [1] > Ah, internal db4o failure on a slight misconfiguration (or rather, a configuration that does not match the configuration the database was created with). Yay for db4o ;) > > So thanks for the inspiration, but I would still say "unable to reproduce" > :( > Further ideas? :) > If not, I might really give up and say "random cosmic X-ray database > breakage" > :| > Let's assume it's just another broken database indeed, however now with new symptoms due to an unfortunate timing of database breakage and WoT upgrading. It should be worthwile to try the backup in this case, as a final workaround. > > In my opinion a missing class index would be an error, for it would > prevent > > Query.constrain(Class) to work with reasonable efficiency. Still, or > should > > not lead to WoT failing to start. > > Yes, I'm right now also having difficulty in imagining a class and query > pattern which wouldn't need a class index. > Perhaps a class which is only queried together with field constrains? But I > don't know whether the field indexes work without the class indexes. > > I should maybe file a bug to test this and possibly remove the > "IndexedClass" > annotation completely. > It don't think there would ever be a good reason to disable class indexes. > OTOH, it will go away anyway once we migrate to something else than db4o. > This > may still be a few years into the future though, I currently still don't > think > that db4o is the reason for WoT's performance issues. > > > [1] > > java.lang.NullPointerException > at > com.db4o.internal.query.result.IdListQueryResult.loadFromClassIndex(IdListQueryResult.java:108) > at > com.db4o.internal.LocalObjectContainer.classOnlyQuery(LocalObjectContainer.java:851) > at > com.db4o.internal.query.processor.QQueryBase.classOnlyQuery(QQueryBase.java:370) > at > com.db4o.internal.query.processor.QQueryBase.getQueryResult(QQueryBase.java:339) > at > com.db4o.internal.query.processor.QQueryBase.execute(QQueryBase.java:328) > at > plugins.WebOfTrust.WebOfTrust.peekDatabaseFormatVersion(WebOfTrust.java:1470) > at plugins.WebOfTrust.WebOfTrust.openDatabase(WebOfTrust.java:630) > at plugins.WebOfTrust.WebOfTrust.runPlugin(WebOfTrust.java:233) > at > freenet.pluginmanager.PluginHandler.startPlugin(PluginHandler.java:44) > at > freenet.pluginmanager.PluginManager.realStartPlugin(PluginManager.java:417) > at > freenet.pluginmanager.PluginManager.startPluginFile(PluginManager.java:390) > at > freenet.pluginmanager.PluginManager.startPluginAuto(PluginManager.java:368) > at > freenet.pluginmanager.PluginManager$3.run(PluginManager.java:249) > at > freenet.support.PooledExecutor$MyThread.innerRun(PooledExecutor.java:248) > at > freenet.support.PooledExecutor$MyThread.realRun(PooledExecutor.java:188) > at freenet.support.io.NativeThread.run(NativeThread.java:157) > _______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
