Difference between revisions of "ESciDoc Cache"

From MPDLMediaWiki
Jump to navigation Jump to search
(yes, was meant server-less, but typed differently)
m
Line 1: Line 1:
==Berkeley DB==
==Purpose==
*Efficient delivery of list of resources generated based on a user query
==Present use cases==
*filtering (methods retrieveItems, retrieveContainers) based on filter criteria
**filter criteria are further translated to a query expression
 
==Basic list requirements==
*list contains full escidoc-xml representation of resources (i.e. mixture of item or container accordingly to item.xsd, container.xsd)
*list contains only authorized resources i.e. the resources the user who requests the list is able to see
*total number of list entries must be known
 
 
===Tools===
====Berkeley DB====
*high performance
*high performance
*high availability
*high availability
Line 9: Line 22:
*check integration with Lucene for administrative searches additionally
*check integration with Lucene for administrative searches additionally


==Lucene==
====Lucene====
*separate index for all latest versions (instead of DBCache) (feasible)?
*separate index for all latest versions (instead of DBCache) (feasible)?
*for items: an item contain all attributes needed to cross-check the authorization
*for items: an item contain all attributes needed to cross-check the authorization

Revision as of 10:33, 23 October 2009

Purpose[edit]

  • Efficient delivery of list of resources generated based on a user query

Present use cases[edit]

  • filtering (methods retrieveItems, retrieveContainers) based on filter criteria
    • filter criteria are further translated to a query expression

Basic list requirements[edit]

  • list contains full escidoc-xml representation of resources (i.e. mixture of item or container accordingly to item.xsd, container.xsd)
  • list contains only authorized resources i.e. the resources the user who requests the list is able to see
  • total number of list entries must be known


Tools[edit]

Berkeley DB[edit]

  • check integration with Lucene for administrative searches additionally

Lucene[edit]

  • separate index for all latest versions (instead of DBCache) (feasible)?
  • for items: an item contain all attributes needed to cross-check the authorization
    • instead of appending SQL to filter, would it be possible to append query to the user query that deals with auth data?
    • is the problem how to actually derive this query?
  • is this also valid for containers? (i.e. an item may be a member of several containers, but i think this has nothing to do)

If this would be possible, no additional cache would be needed?