Good to hear that at least the XML-import+SMW-refresh finally worked. The design of MediaWiki is very fragile in many places, and I fear that there are much more non-common cases where extensions do not work as expected (e.g. due 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/SemanticMediaWiki
> /includes/articlepages/SMW_PropertyPage.php on line 68, referer: http://<mw
> base url>/index.php?title=Special%3AAllpages&from=&namespace=102
>
> so I enabled SQL debug and looked at the queries and realized that only few
> of the pages that were returned by SMW::getAllPropertySubjects had entries
> 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 data
related to existing subjects. If for some reason there are entries of
annotations for articles that do not exist, then these are not fixed by any
amount of refreshing. This is what happened in the above case (the title
object did not exist).
I have now extended the storage implementation to catch this case, but we
should also have some script that resets the SMW-tables completely.
>
> 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 rebuild
> stuff from scratch?
Yes, that should work.
> BTW, is it OK to split SMW_refreshData task to several
> 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
you cannot currently tell them to stop at some fixed ID other than by editing
the script. Doing this may improve performance if CPU is a bottleneck for you
(in some cases, DB bandwidth or working memory may be the bottleneck), and if
your OS really distributes sub-processes between the CPUs (my observation is
that a single wiki, even if processing many requests in parallel, often uses
only one of our server CPUs; this may be related to the single mysql-server
that creates DB-processes; anyway it is handy since a high-load wiki doesn't
ever lock the whole server but only one CPU).
Markus
>
> Sergey
>
> On Nov 9, 2007 7:11 AM, Markus Krötzsch <[EMAIL PROTECTED]> wrote:
> > 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 the
> > 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 recreate
> > 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 <[EMAIL PROTECTED]> 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 sure
> > > > 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 = 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
> > > > [[Äàòà:=13.04.2007]]
> > > > where Aaoa is a Date in Russian, like:
> > > > [[Date:=13.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
> >
> > -------------------------------------------------------------------------
> >
> > > > 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
> > > > Semediawiki-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
> >
> > --
> > Markus Krötzsch
> > Institut AIFB, Universät Karlsruhe (TH), 76128 Karlsruhe
> > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998
> > [EMAIL PROTECTED] www http://korrekt.org
> >
> > -------------------------------------------------------------------------
> > 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
> > Semediawiki-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
--
Markus Krötzsch
Institut AIFB, Universät Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362 fax +49 (0)721 608 5998
[EMAIL PROTECTED] www http://korrekt.org
pgphLpCTkCims.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
