From: Reini U. <ru...@x-...> - 2005-01-07 19:30:46
|
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). > >> Other than helping administrative SQL tasks outside the wiki maybe. >> Schema upgrades are done now via action=upgrade. >> But a simple mysql script is also easy, looping over all existing >> prefixes. Should I provide such a script for wikifarm schema upgrades? > > I think that wikifarm users are able to do their own upgrades. > >> But for gforge integration it is really not needed. > > I discuss very long time with Christian Bayle from gforge team and we > have the same felling: "multiplication of tables is bad" but without > rational facts to justify our feeling. > > 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/ |