User Tools

Site Tools


info:devel:cceindex

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
info:devel:cceindex [2016/01/12 21:40]
info:devel:cceindex [2016/01/16 16:41] (current)
[What now]
Line 27: Line 27:
  
 ==== Data Integrity ==== ==== Data Integrity ====
-As mentioned above, there have been numerous occasions where the current indexes have been out of sync between the used OID list, the OID directory, and the class index. There are scripts available to rebuild the allocated OID list, but there is currently no tool available to rebuild the class index. When this file gets corrupted, there is a requirement to build a new server... or engage Michael who has some custom scripts that rebuild the entire CODB database. But these scripts are not released to the public as they are not currently ​available ​for production use.+As mentioned above, there have been numerous occasions where the current indexes have been out of sync between the used OID list, the OID directory, and the class index. There are scripts available to rebuild the allocated OID list, but there is currently no tool available to rebuild the class index. When this file gets corrupted, there is a requirement to build a new server... or engage Michael who has some custom scripts that rebuild the entire CODB database. But these scripts are not released to the public as they are not currently ​ready for production use.
  
 ===== The Future ===== ===== The Future =====
Line 56: Line 56:
  
 ===== What now ===== ===== What now =====
-Before writing any pseudo codeI think we need to review the existing ​CODB code and documentation ​to see what was intended ​by the Cobalt designers+OK. So lets talk about the future... 
 + 
 +Assumption 1. We don't want to index everything. If we did thatthe overhead would be massive, and the overhead would be undesirable. 
 + 
 +Assumption 2. If we don't want to index everything, we want to  have CODB "​learn"​ what to index based on past queries, rather than have a static definition of what needs to be indexed. 
 + 
 +So - lets talk about the code 
 + 
 +==== FIND ==== 
 + 
 +We would have ONE index file. That file would initially have no entries. The first time we do a CODB find on an attribute, the call would go to the legacy CODB process. If the number of objects returned is greater than one, we would create index entries for each of the attributes that were part of the search criteria. The index KEY would be class.<​optional-namespace>​.key.hash,​ with the OID's matched. In addition to this, we would add an index entry to the same file isindexed.class.<​optional-namespace>​.key with a return value of 1. 
 + 
 +Future find requests would check if a key is indexed first. And if it is, the index will be used to return a result. If there are multiple attributes being searched, the result will be an set intersection of searches across each of the attributes being searched 
 + 
 +==== SET ==== 
 +Set transactions will similarly search the isindexed for each of the attributes being modified. For each attribute being changed, it will first 1. Delete the index entry for the previous value, ​and 2. Add a new index entry for the new value. 
 + 
 +==== CREATE ==== 
 + 
 +For each CREATE request, the system will look at isindexed for each attribute being stored. If an attribute is marked as indexed, a new entry will be added to the index for the respective attribute values. 
 + 
 +==== DESTROY ==== 
 + 
 +For each DESTROY request, the system will look at all current attributes. For all isindexed attributes, the system will destroy index entries for corresponding attributes. Or, better still - if the index allows searching ​by OID's, the system will destroy all index entries for the matching OID being destroyed.
info/devel/cceindex.1452595246.txt.gz · Last modified: 2016/01/12 21:40 by