2008/1/20, rssh <[EMAIL PROTECTED]>: > > > > isVirtual is just an information XWiki use to know if it's in virtual > > mode or not. If you allow setDatabase in non-virtual mode you will be > > "physically" in virtual mode. That means you can access any wiki in > > the same database just using context.setDatabase from Velocity. It's > > a big difference at least for security when you have more than one > > XE in the same database. Another thing is that setDatabase is called > > understand. [A] > > > for each query and execute "SET SCHEMA" or anything else depends of > > database type and it will double queries in non-virtual mode to > > always switch from wiki "wikiname" to "wikiname". > > > > If we does not call setScheme, that hibernate do this (for scheme-based > databases) during each initialization of XWiki, which we usually have on > each web request. So, I does not guess big difference in performance. [B]
You have at least initHibernate() that is called only at first request.. > > > > There is others ways to do what you want like calling setDatabase > > with a parameter "force" at database init for example only if > > "wiki.db" is set. > > > > Ok, I will look. > > Is the next strategy will be accessible (?) : > > 1. add to xwiki boolean member variable, which means, that 'database does not > yet initialized'. > 2. enable setDatabase in non-virtyal mode only if we does not call yet > 'setDatabase' for this xwiki instance. > > This will fix security issue 'A' and partially - reduce extra overhead in 'B'. > > So, is this plan looks normal ? > Yes, this sounds good to me. > > > > I don't say virtual/non-virtual separation can't be removed but it's > > another subject and imply more than just "allows to configurate name > > of database schema". > > > > > > > > > > > > > > > > > > > > > patch is attached (tested with hsql in non-virtual mode in addition > to oracle > > > > > in virtual/unvirtual). I will attach one to jira thought few seconds. > > > > > > > > > > P.S. also note, that exitsts hibernate property 'default_schema' > which (when > > > > > we change name) must not conflict with xwiki.db > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > devs mailing list > > > > > > > [email protected] > > > > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > > > > > > > > -- > > > > > > Thomas Mortagne > > > > > > _______________________________________________ > > > > > > devs mailing list > > > > > > [email protected] > > > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > > > > > > > > > -- > > > > > Ruslan Shevchenko > > > > > GradSoft. http://www.gradsoft.ua > > > > > > > > > > > > > > > _______________________________________________ > > > > > devs mailing list > > > > > [email protected] > > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Thomas Mortagne > > > > _______________________________________________ > > > > devs mailing list > > > > [email protected] > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > -- > > > Ruslan Shevchenko > > > GradSoft. http://www.gradsoft.ua > > > > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > -- > > Thomas Mortagne > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Ruslan Shevchenko > GradSoft. http://www.gradsoft.ua > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > When you will have a nice implementation that works on all databases, this feature will need a vote I think as it touch a very important part of XWiki engine. -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
