I ran the following queries on a wiki containing 5735 documents, with the proper mysql indexes:
"select distinct doc.space from XWikiDocument doc, BaseObject obj, StringProperty as prop where doc.fullName=obj.name and obj.className='XWiki.XWikiRights' and obj.id=prop.id.id and prop.id.name='allow' and prop.value=1" - First execution: 235ms "select distinct doc.space from XWikiDocument doc where (doc.hidden <> true or doc.hidden is null)" - First execution: 40ms Now with the mysql query cache performing the same queries multiple times flattens the initial big difference. Results when running the queries above 1000 times in a row: XObject: 446ms doc.hidden: 361ms Now I wonder how much we can rely on the mysql query cache to guarantee our performance. On Thu, Mar 22, 2012 at 5:13 PM, Anca Luca <[email protected]> wrote: > On 03/21/2012 09:07 PM, Sergiu Dumitriu wrote: >> >> On 02/13/2012 11:27 AM, Vincent Massol wrote: >>> >>> Hi devs, >>> >>> I've been brainstorming with Jean-Vincent about how to implement hiding >>> technical content for 4.0. Here's what we would like to do: >>> Note: This is related to the proposal I made earlier: >>> http://markmail.org/thread/jupn22fdk4nnqj6p >>> >>> In summary: >>> >>> * Add a RoleVisibilityClass XObject to documents and spaces (in >>> WebPreferences for Spaces) which is a list of Roles (simple or advanced >>> users for now) deciding which role should be allowed to view a given >>> document in result sets. >> >> >> Should we use different objects for different levels of rights? For >> example, we have XWikiRights and XWikiGlobalRights to distinguish between >> rights on the WebPreferences document itself and rights on the whole space. >> If we always assume that a RoleVisibilityClass object on a WebPreferences >> document always refers to the space visibility, then we will have to rely on >> the blacklist to hide all WebPreferences documents. Is that something we >> want to hardcode? >> >> An alternative that doesn't require using two classes is to add a "scope" >> property to the class, to distinguish between document, space and wiki >> settings. >> >>> * Either modify XWikiHibernateStore or introduce a new >>> FilteredHibernateStore store which would delegate to XWikiHibernateStore >>> (same mechanism as the cache store) to add the JOIN to check the visibility >>> and only return visible documents for the current user >> >> >> I'd rather use a new store interface, since I've changed the default store >> to exclude the "hidden" documents from results, and this is making it hard >> to ignore the hidden setting even from internal code. >> >>> * Remove the notion of hidden documents and have a migrator to remove the >>> column in xwikidocs >> >> >> +1. >> >>> * Modify the Lucene plugin to add a VISIBILITY field and return filtered >>> results based on the visibility and the current user role >> >> >> +1. >> >>> * Note1: After much brainstorming we think that the notion of >>> "application" could be implemented either with an Application XObject that >>> tie the document to an application or with an Application Descriptor. >>> * Note2: We'll need to decide at some point if we want more roles than >>> just "simple user" and "advanced user" and if we need "developer" and >>> "admin" too. >> >> >> +1 for more roles in the future. >> >>> * Notes1 and 2 are currently out of scope for this proposal >>> >>> However we're wondering how much performance we will loose with this >>> implementation using XObjects (due to the extra JOIN). > > > That would be 2 extra joins (compared to selecting just documents) so I > would say yes, the impact is non-negligible, even with proper indexes. > > >> >> With the proper indexes in place, and if we only use this check when >> running queries from the wiki, it shouldn't have a big impact. >> >>> Do you think it's acceptable? >>> >>> Could it be improved with custom mapping? (I think not) >> >> >> Not that much, custom mapping helps only when there are objects with lots >> of properties in them. >> >>> Should we implement this without XObjects and instead modify >>> XWikiDocuments and add a new column in xwikidocs? >> >> >> This would be better for performance (less joins). >> >>> Thanks >>> -Vincent >>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Jean-Vincent Drean, XWiki. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
