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?

And besides: Your suggested procedure does indeed cause it to throw, but with
a different stack trace :|  See [1]

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" 
:|

> 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.
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)

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to