From: Christian B. <chr...@fr...> - 2005-01-14 23:03:13
|
Le vendredi 07 janvier 2005 =E0 20:30 +0100, Reini Urban a =E9crit : > Manuel VACELET schrieb: > > Reini Urban wrote: > >=20 > >> I'll have a look after 1.3.11 but I still see no technical reason, why= =20 > >> this should be better than tablename prefixes. Merging all the=20 > >> seperate table sets into one big mess... > >=20 > > I agree, it's not technical reasons. > > I just "fell" it not very elegant (tables multiplications). > >=20 I see finally some important technical reasons after some discussion:=20 -Upgrading 4000 set of tables can be some kind of tricky. 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 Thanks for your help Cheers Christian.=20 > >=20 > > Current way of phpwiki integration under gforge is to have only one wik= i=20 > > and each project create pages into this big wiki. My way is to provide=20 > > one independent wiki for each project. >=20 > Well, my way for gforge intergration would use a project-specific=20 > DATABASE_PREFIX, set by the plugin. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > I cannot accept your page.group_id patch into phpwiki. > It is way to abusive. >=20 > > Current state seems to work (around 1 month of tests without any=20 > > problems) but I prefer waiting for phpwiki 1.3.11 release before releas= e=20 > > the plugin. >=20 > The sql schema will not change anymore for sure. > Maybe some minor issues with exotic backends have to fixed. >=20 > Major goals are only the request enhancements in main and Request > (GET =3D> POST for ModeratedPage, maybe edit), check remaining request=20 > problems (session, edit + redirect) > wikiparser fixes for php5 (or output?), > some remaining theme updates > configurator for lists |