Re: [Phpwiki-talk] Multiple instances - One DB

[Reini U. <ru...@x-...>]

Christian BAYLE schrieb:
> Le vendredi 07 janvier 2005 à 20:30 +0100, Reini Urban a écrit :
>>Manuel VACELET schrieb:
>>>Reini Urban wrote:
>>>
>>>>I'll have a look after 1.3.11 but I still see no technical reason, why 
>>>>this should be better than tablename prefixes. Merging all the 
>>>>seperate table sets into one big mess...
>>>
>>>I agree, it's not technical reasons.
>>>I just "fell" it not very elegant (tables multiplications).
> 
> I see finally some important technical reasons after some discussion: 
> -Upgrading 4000 set of tables can be some kind of tricky.

A simple perl or php script?

> The main question is to have isolated group spaces in the wiki, that is
> not as far as i understand in phpwiki philosophy.
> -Having group of pages associated with a project, where you can make
> some kind of access control possibly at page level: public or private.
> -Each project gathering a group of users.
> 
> How would you implement this, if you had to do it, is the way followed
> by Manuel the best one, according to the fact we don't want database or
> table multiplication

Ok. I see your point now.
auth and perm control, across groups:

access control by group level (public or private) would be easy by 
defining this constant in the starter script, dependent on the group_id. 
(some pgsql query from the gforge cfg).
if (

user auth (userid+passwd) is already easy via external db.

also via session:
// If the user is logged in, let the Wiki know
if (session_loggedin()) {
     // let php do it's session stuff too!
     session_start();
     $_SESSION['user_id'] = user_getname(); // phpwiki will pick it up.
}
or via the undocumented Session auth:
         define('AUTH_SESS_USER', 'user_id');
         define('AUTH_SESS_LEVEL', 2);
         $USER_AUTH_ORDER = "Session : PersonalPage";
         $USER_AUTH_POLICY = "stacked";

db upgrade:
table schema multiplication might be problematic, but could be done by 
some simple helper script. It's technically not the best solution, but 
at least the tables are fully independent. ISP's usually prefer 
independence over technical superiority.
A seperate database per group is technically and in administrative terms 
the worst solution.

Your required wikidb patch for the queries (WHERE group_id=) is  quite 
simple. That would fit best to the gforge philosophy.

>>>Current way of phpwiki integration under gforge is to have only one wiki 
>>>and each project create pages into this big wiki. My way is to provide 
>>>one independent wiki for each project.
>>
>>Well, my way for gforge intergration would use a project-specific 
>>DATABASE_PREFIX, set by the plugin.
>>
>>DB: phpwiki
>>   tables: project1_page, project1_version, project1_recent, ...
>>           project2_page, project2_version, project2_recent, ...
>>needs project_name
>>you can even use different wiki engines per project.
>>
>>Your id scheme is simplier on the database level.
>>DB: phpwiki
>>   tables: page (with group_id), version, recent, ...
>>needs group_id
>>just one engine and one database schema.
>>
>>Pro:  * You only have to do structure updates once,
>>         and use a new primary index: pagename+id
>>       * easier to upgrade to a new phpwiki schema and version.
>>Cons: * Seperation into different wiki's is hard.
>>       * you cannot do project specific phpwiki updates.
>>       * will not by supported by phpwiki OOTB.
>>         So gforge sites must patch the WikiDB backends.
>>
>>I cannot accept your page.group_id patch into phpwiki.
>>It is way to abusive.
>>
>>
>>>Current state seems to work (around 1 month of tests without any 
>>>problems) but I prefer waiting for phpwiki 1.3.11 release before release 
>>>the plugin.
>>
>>The sql schema will not change anymore for sure.
>>Maybe some minor issues with exotic backends have to fixed.
>>
>>Major goals are only the request enhancements in main and Request
>>(GET => POST for ModeratedPage, maybe edit), check remaining request 
>>problems (session, edit + redirect)
>>wikiparser fixes for php5 (or output?),
>>some remaining theme updates
>>configurator for lists
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/