 |
Page History
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
//This Index “template” interface directly calls Lucene reader/write elements. It’s base and multi-base implementations will need to be adjusted //to some extent, but it’s clear that some support still exists for multiple index reading/writing. Some of both will have to be maintained for the //remaining MetaData index search (different from the metadata.xml) and possibly the simple search. org.lexevs.dao.index.lucenesupport.LuceneIndexTemplate //The Dao layer will need a new start. Lucene 5.0 creates a clean break with previous Lucene formats. A format aware Dao for going forward //may provide some future proofing so we’ll continue to build on it, but at the same time break with the previous format support org.lexevs.dao.index.access.LexEvsIndexFormatVersionAwareDao org.lexevs.dao.index.access.AbstractBaseIndexDao org.lexevs.dao.index.lucene.AbstractFilteringLuceneIndexTemplateDao org.lexevs.dao.index.lucene.AbstractBaseLuceneIndexTemplateDao org.lexevs.dao.index.lucene.v2010.entity.LuceneEntityDao org.lexevs.dao.index.lucene.v2010.entity.SingleTemplateDisposableLuceneCommonEntityDao |
Moving Towards an MMapDirectory Type
MMapDirectories offer an opportunity to take advantage of modern operating system memory management. In effect we set aside resources to insure that Lucene has enough memory available at all times. This is similar to what happens when you set up databases and other applications that need a minimum of resources in order to function properly. In essence we have a contract to get transparent memory resources as a virtual memory bank of RAM and Storage. Because we don't compete with other resources for this memory we are able to process indexing and search tasks more efficiently.
Changing the Relational Representation in Lucene
...
