From: Markus <ma...@ai...> - 2007-11-23 08:49:41
|
Good to hear that at least the XML-import+SMW-refresh finally worked. The=20 design of MediaWiki is very fragile in many places, and I fear that there a= re=20 much more non-common cases where extensions do not work as expected (e.g. d= ue=20 to the combination of global and non-global objects everywhere in the code). Some minor remarks follow. On Freitag, 9. November 2007, Sergey Chernyshev wrote: > Yes, I ran SMW_refreshData twice - first with -p and second without. > The problem I ran into is that Property page complained like this: > > PHP Fatal error: Call to a member funct > ion getText() on a non-object in /<path to mw>/extensions/SemanticMediaWi= ki > /includes/articlepages/SMW_PropertyPage.php on line 68, referer: http://<= mw > base url>/index.php?title=3DSpecial%3AAllpages&from=3D&namespace=3D102 > > so I enabled SQL debug and looked at the queries and realized that only f= ew > of the pages that were returned by SMW::getAllPropertySubjects had entri= es > in mw_page (hmm, it seems that I got you confused saying that I lacked > entries in mw_smw_attributes - looks like I got them referencing wrong ids > or non-existing pages). Ah, now I see the problem: refreshing all data will only ever delete the da= ta=20 related to existing subjects. If for some reason there are entries of=20 annotations for articles that do not exist, then these are not fixed by any= =20 amount of refreshing. This is what happened in the above case (the title=20 object did not exist). I have now extended the storage implementation to catch this case, but we=20 should also have some script that resets the SMW-tables completely. =20 > > I'm thinking of dropping all SMW tables and re-running the SMW_Setup.php > and then SMW_refreshData twice. Do you think is a right approach to rebui= ld > stuff from scratch?=20 Yes, that should work. > BTW, is it OK to split SMW_refreshData task to several=20 > tasks and run them simultaneously for better use of multiple CPUs I have? You can run several instances with different page IDs to start refreshing, = but=20 you cannot currently tell them to stop at some fixed ID other than by editi= ng=20 the script. Doing this may improve performance if CPU is a bottleneck for y= ou=20 (in some cases, DB bandwidth or working memory may be the bottleneck), and = if=20 your OS really distributes sub-processes between the CPUs (my observation i= s=20 that a single wiki, even if processing many requests in parallel, often use= s=20 only one of our server CPUs; this may be related to the single mysql-server= =20 that creates DB-processes; anyway it is handy since a high-load wiki doesn'= t=20 ever lock the whole server but only one CPU). Markus > > Sergey > > On Nov 9, 2007 7:11 AM, Markus Kr=F6tzsch <ma...@ai...> wro= te: > > On Donnerstag, 8. November 2007, Sergey Chernyshev wrote: > > > Not sure if it's related to this issue, but I also lost some data in > > > smw_attributes table (not all of it though). The worst part is that it > > > didn't reappear after I ran complete SMW_refreshData on the dataset. > > > I wonder what needs to be done to repopulate SMW tables from scratch? > > > > Running SMW_refreshData twice (once with option -p and once without; > > option -v > > may also be interesting but not essential) will restore all available > > data in > > basically all cases. If the table remains incomplete, this means that t= he > > content of the pages does no longer require certain entries there. This > > may > > have various reasons: > > > > * The table contained old orphaned entries before, maybe due to some bug > > in > > earlier versions. > > * The table contained outdated data (e.g. after some template change) > > that just had not been refreshed yet. > > * Some annotation is no longer accepted, maybe due to (unintentional) > > syntactic changes, or due to known limitations such as the disabled > > Type:Boolean. > > > > Only case 3 should bother you, and in this case more information is > > needed: > > what exactly is it that is missing? > > > > But in any case SMW_refreshData (at least in theory) suffices to recrea= te > > all > > SMW data from scratch or from import. Anything not built there will not > > be built when editing pages normally either. > > > > Markus > > > > > Sergey > > > > > > On Nov 8, 2007 8:26 AM, cnit <cn...@un...> wrote: > > > > > Yes, this appears to be a bug. For a quick workaround, consider > > > > using > > > > > > the > > > > > > > > > formats "list", "ul" or "ol", all of which also support the > > > > > template-parameter for formatting (and this one certainly works > > > > > with > > > > > > > > SMW1.0). > > > > > > > > > Note that with list, you can also choose the separator between > > > > > items (parameter sep), so as to simulate "template" quite well. > > > > > > > > Thanks for a hint, but it seems that the problem is deeper. Even > > > > after the successfully importing XML dump, where > > > > <page>Attribute:..</page> > > > > were replaced with > > > > <page>Property:..</page> > > > > > > > > and also these pages were placed on the top of the dump, to make su= re > > > > properties are defined before importing the pages where actual > > > > values of properties are used.. > > > > > > > > But.. my smw_attributes table is empty :-( I think it's not > > > > correct, because I have at least two properties and many user pages > > > > that use them.. > > > > > > > > My first guess was: "that might be because the datetime class was > > > > completely rewritten, and the new version doeesn't accept Russian > > > > format of dates". But, I've made a simple test and it seems that > > > > > > > > $this->m_time =3D strtotime(trim($value)); > > > > > > > > converts Russian formatted date > > > > strtotime("13.04.2007") > > > > to correct value. > > > > > > > > There is a page, which uses Date property with such value, yet, the > > > > manual Special:Ask search of > > > > [[=C4=E0=F2=E0:=3D13.04.2007]] > > > > where Aaoa is a Date in Russian, like: > > > > [[Date:=3D13.04.2007]] > > > > > > > > returns nothing. Yet, the page with such property value exists in > > > > the wiki.. > > > > > > > > The property also has it's own definition page (of course), which > > > > states (in Russian) that it's a special one and it's type belongs > > > > to standard type "Date" - there are mouseover popup hints. I guess > > > > that > > > > > > means that property has been defined correctly? > > > > > > > > I guess that SMW tables aren't initialized during the XML import for > > > > some > > > > > > reason? > > > > Dmitriy > > > > -----------------------------------------------------------------------= =2D- > > > > > > This SF.net email is sponsored by: Splunk Inc. > > > > Still grepping through log files to find problems? Stop. > > > > Now Search log events and configuration files using AJAX and a > > > > browser. > > > > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > > _______________________________________________ > > > > Semediawiki-devel mailing list > > > > Sem...@li... > > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > -- > > Markus Kr=F6tzsch > > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > > ma...@ai... www http://korrekt.org > > > > -----------------------------------------------------------------------= =2D- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Semediawiki-devel mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |