[xwiki-devs] [Brainstorming] Hiding technical content
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. * 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 * Remove the notion of hidden documents and have a migrator to remove the column in xwikidocs * Modify the Lucene plugin to add a VISIBILITY field and return filtered results based on the visibility and the current user role * 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. * 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). Do you think it's acceptable? Could it be improved with custom mapping? (I think not) Should we implement this without XObjects and instead modify XWikiDocuments and add a new column in xwikidocs? Thanks -Vincent
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).
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
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Wed, Mar 21, 2012 at 9:07 PM, Sergiu Dumitriu <[email protected]> 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.
I still think that we could finish what you've started with XWikiDocument#isHidden() by: - moving it to the query manager - making it easy to disable the filtering, with a per-call or per-user setting - allowing to mark a document as hidden from the UI (the checkbox would only be displayed to users who decided to display hidden documents) - get the list of spaces with : -------------------------------------------------------8<----------------------------------------------------- select distinct doc.space from XWikiDocument doc where (doc.hidden <> true or doc.hidden is null) order by doc.space asc -------------------------------------------------------8<----------------------------------------------------- - mark all the technical documents in our distribs as hidden For example It would allow to display the XWiki space in the list of spaces but (by default) the list of pages within this space would be the list of user documents. The scheduler space wouldn't appear because it only contains technical documents.
* 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.
We discussed another way to do this with Vincent: - new QueryFilter interface, with one method QueryFilter#filter(String statement, String language) - new Query.setFilter(Filter)/getFilter() methods (could be add/remove) - Query.getStatement() returns the filtered statement if there's a filter to apply I have a PoC with a TechnicalContentFilter (but TBH I'd rather name it HiddenDocumentFilter) which encapsulate the old XWikiHibernateStore doc.hidden filtering. I do a setFilter(new TechnicalContentFilter()) in the DefaultQuery construtor and it works fine. It could be extended and it's easily "disableable" through Query#setFilter(null). The only think I'm not sure how to resolve is the filtering of named queries, I can't think of an easy way to support them with what is explained above.
* 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.
We talked about the first 5 minutes with Caty, also about roles and the fact that having an arbitrary mapping between roles (simple/advanced) and displayed actions/items (hidden pages, keyboard shortcuts, etc) may not be the best way to do it. What we talked about was: - display a "Get started" wizard the first time a user logs in (it was actually the starting point of the discussion) - when the user finishes or dismisses the wizard, he's asked to choose a "flavor": simple, advanced, developer, etc - choosing a flavor sets some properties (display hidden documents, enable keyboard shortcuts, watch whole wiki for admins, etc) in his profile. Note: since those props will be set to "yes/no" but not "undefined" we could know if the user went through the get started guide by checking the value of one of this prop. - a user can later fine tune his settings by editing his preferences WDYT ?
* 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).
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
-- Sergiu Dumitriu http://purl.org/net/sergiu/
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean-Vincent Drean, XWiki.
On 03/22/2012 09:56 AM, Jean-Vincent Drean wrote:
On Wed, Mar 21, 2012 at 9:07 PM, Sergiu Dumitriu<[email protected]> 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.
I still think that we could finish what you've started with XWikiDocument#isHidden() by:
- moving it to the query manager - making it easy to disable the filtering, with a per-call or per-user setting - allowing to mark a document as hidden from the UI (the checkbox would only be displayed to users who decided to display hidden documents) - get the list of spaces with : -------------------------------------------------------8<----------------------------------------------------- select distinct doc.space from XWikiDocument doc where (doc.hidden<> true or doc.hidden is null) order by doc.space asc -------------------------------------------------------8<----------------------------------------------------- - mark all the technical documents in our distribs as hidden
For example It would allow to display the XWiki space in the list of spaces but (by default) the list of pages within this space would be the list of user documents. The scheduler space wouldn't appear because it only contains technical documents.
* 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.
We discussed another way to do this with Vincent: - new QueryFilter interface, with one method QueryFilter#filter(String statement, String language) - new Query.setFilter(Filter)/getFilter() methods (could be add/remove) - Query.getStatement() returns the filtered statement if there's a filter to apply
I have a PoC with a TechnicalContentFilter (but TBH I'd rather name it HiddenDocumentFilter) which encapsulate the old XWikiHibernateStore doc.hidden filtering. I do a setFilter(new TechnicalContentFilter()) in the DefaultQuery construtor and it works fine. It could be extended and it's easily "disableable" through Query#setFilter(null).
The only think I'm not sure how to resolve is the filtering of named queries, I can't think of an easy way to support them with what is explained above.
* 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.
We talked about the first 5 minutes with Caty, also about roles and the fact that having an arbitrary mapping between roles (simple/advanced) and displayed actions/items (hidden pages, keyboard shortcuts, etc) may not be the best way to do it. What we talked about was:
- display a "Get started" wizard the first time a user logs in (it was actually the starting point of the discussion) - when the user finishes or dismisses the wizard, he's asked to choose a "flavor": simple, advanced, developer, etc - choosing a flavor sets some properties (display hidden documents, enable keyboard shortcuts, watch whole wiki for admins, etc) in his profile. Note: since those props will be set to "yes/no" but not "undefined" we could know if the user went through the get started guide by checking the value of one of this prop. - a user can later fine tune his settings by editing his preferences
WDYT ?
That's for another thread, but in principle I agree.
* 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).
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).
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Thu, Mar 22, 2012 at 4:45 PM, Sergiu Dumitriu <[email protected]> wrote:
On 03/22/2012 09:56 AM, Jean-Vincent Drean wrote:
On Wed, Mar 21, 2012 at 9:07 PM, Sergiu Dumitriu<[email protected]> 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.
I still think that we could finish what you've started with XWikiDocument#isHidden() by:
- moving it to the query manager - making it easy to disable the filtering, with a per-call or per-user setting - allowing to mark a document as hidden from the UI (the checkbox would only be displayed to users who decided to display hidden documents) - get the list of spaces with :
-------------------------------------------------------8<----------------------------------------------------- select distinct doc.space from XWikiDocument doc where (doc.hidden<> true or doc.hidden is null) order by doc.space asc
-------------------------------------------------------8<----------------------------------------------------- - mark all the technical documents in our distribs as hidden
For example It would allow to display the XWiki space in the list of spaces but (by default) the list of pages within this space would be the list of user documents. The scheduler space wouldn't appear because it only contains technical documents.
* 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.
We discussed another way to do this with Vincent: - new QueryFilter interface, with one method QueryFilter#filter(String statement, String language) - new Query.setFilter(Filter)/getFilter() methods (could be add/remove) - Query.getStatement() returns the filtered statement if there's a filter to apply
I have a PoC with a TechnicalContentFilter (but TBH I'd rather name it HiddenDocumentFilter) which encapsulate the old XWikiHibernateStore doc.hidden filtering. I do a setFilter(new TechnicalContentFilter()) in the DefaultQuery construtor and it works fine. It could be extended and it's easily "disableable" through Query#setFilter(null).
The only think I'm not sure how to resolve is the filtering of named queries, I can't think of an easy way to support them with what is explained above.
* 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.
We talked about the first 5 minutes with Caty, also about roles and the fact that having an arbitrary mapping between roles (simple/advanced) and displayed actions/items (hidden pages, keyboard shortcuts, etc) may not be the best way to do it. What we talked about was:
- display a "Get started" wizard the first time a user logs in (it was actually the starting point of the discussion) - when the user finishes or dismisses the wizard, he's asked to choose a "flavor": simple, advanced, developer, etc - choosing a flavor sets some properties (display hidden documents, enable keyboard shortcuts, watch whole wiki for admins, etc) in his profile. Note: since those props will be set to "yes/no" but not "undefined" we could know if the user went through the get started guide by checking the value of one of this prop. - a user can later fine tune his settings by editing his preferences
WDYT ?
That's for another thread, but in principle I agree.
Yes, I was mentioning it because it doesn't fit with the role/visibility proposal.
* 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).
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).
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean-Vincent Drean, XWiki.
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
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.
On Fri, Mar 23, 2012 at 11:17 AM, Jean-Vincent Drean <[email protected]> wrote:
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
s/StringProperty/IntegerProperty/
"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.
-- Jean-Vincent Drean, XWiki.
participants (4)
-
Anca Luca -
Jean-Vincent Drean -
Sergiu Dumitriu -
Vincent Massol