Markus:
Actually, I just managed to bring my custom data type into compliance
with Version 1.5bSVN. And it does not use parseDBkeys or getDBkeys, but
rather does things the old way. (I noticed that Autoloading is now moved
to SMW_GlobalFunctions.php and out of SMW_DataValueFactory.php, and that
the Tooltip header call has been changed. Once I made those changes, all
the software loaded without difficulty.)
Tell me again, please, and in detail, how to implement parseDBkeys and
getDBkeys. Are you saying that I should take the same code I implemented
once before for getXSDValue and parseXSDValue, but reconfigure the
output as a single-element array?
Regarding unstub(): So all "get" methods must call this function at the
first?
What is this new special property "Modification date"? How do I describe
it so that it stops showing up as a redlink on the Browse page?
Temlakos
Markus Krötzsch wrote:
> On Sonntag, 1. März 2009, Yaron Koren wrote:
>
>> Yeah, the SQL store changed in SMW 1.4; or rather, SMWSQLStore2, which had
>> previously been optional, became mandatory. It's pretty easy to upgrade to
>> the new store: go to "Special:SMWAdmin", and click on the button
>> "Initialise or upgrade tables"; and when that's done, click on the button
>> "Start updating data". This won't delete any of the data in the old SQL
>> store, if that's a concern.
>>
>
> Right, you need to follow the usual upgrade instructions, no matter whether
> you have a custom datatype or not. The Installation article on semantic-
> mediawiki.org gives some details (maybe see also the according page for older
> releases). This upgrade should work on 1.3 already, so that you can separate
> it from potential problems with your custom code. In any case, you need to
> initialise the DB tables again after each version upgrade (but this is rather
> quick, since it does not require a complete refresh of all data like the
> initial setup of the new store).
>
> Regarding the datatypes, there have been minimal extensions of the API. In
> particular, there are new functions getDBkeys() and parseDBkeys() that take
> the place of the old getXSDValue() and parseXSDvalue() (which do still exist
> but should avoid to be used now). They are easy to implement, essentially just
> like the XSD-functions but with arrays as input and output (the arrays are
> often singleton but not for all datatypes). See SMW_DV_String.php for an
> example, and see the documentation in SMW_Datavalue.php for details and
> rationale. You should see PHP errors that point this out.
>
> Moreover, all datatypes now have a built-in stubbing mechanism, and you need
> to call unstub() before accessing any of their values. Again, String is a
> simple example. Whenever a datavalue is read from the DB, the parseDBkeys()
> method is not called immediately, but this call is deferred until the first
> unstub() -- so if you forget to call this, the value object will not have its
> variables initialised properly after being read from DB (e.g. in query results
> or Special:Browse).
>
> I think hose two changes should be all.
>
> -- Markus
>
>
>> -Yaron
>>
>> On Sat, Feb 28, 2009 at 1:03 PM, Temlakos <temlakos@...> wrote:
>>
>>> Markus (and Yaron and anyone else who might be able to help):
>>>
>>> Today I upgraded my wiki from MediaWiki 1.12 to 1.14. After a few false
>>> starts (because one of the extensions had some case changes in its
>>> name), the upgrade and schema update is now complete.
>>>
>>> But then I tried to update SMW to the code now in Subversion (SMW 1.5b).
>>>
>>> This code "broke" my Historical Date data type. Now before you ask why I
>>> don't simply make "Historical Date" an alias for "Date", let me remind
>>> you that when you changed SMW_DVTime (the "Date" data type) to use its
>>> own parser instead of the Unix strtotime() call, you did not implement
>>> my "Anno Mundi" calendar nor even the Hillel II (Jewish) calendar. Those
>>> are deal-killers.
>>>
>>> I was able to roll everything back to SMW 1.3. Which means that my
>>> SMW_HxDateValue class works properly with the old code.
>>>
>>> So what exactly did you change in the implementation of SMW_DataValue,
>>> that puts my custom data type out of compliance? What sort of things
>>> should I check for?
>>>
>>> Does the total size of the file have anything to do with it? My file
>>> SMW_DVHxDate.php is 44 KB in size. Is that a deal-killer in SMW 1.4 and
>>> higher?
>>>
>>> I think the real problem is that you have changed the store. How do I
>>> know that? Well, when I installed the code checkecd out of Subversion, I
>>> ran the refresh script. That's when everything broke. Then I rolled my
>>> code back, but whenever I went to a page containing an annotated
>>> historical date, I got a "database error" notice, and the error traced
>>> to the SMW store (something about an "unknown column" in a table). So I
>>> had to run refreshData by hand multiple times, and when I did that,
>>> everything worked the way it always had.
>>>
>>> Bottom line: I'm likely to stay permanently at SMW 1.3 unless I can get
>>> some assistance on how to migrate my custom date datatype to comply with
>>> the new code.
>>>
>>> Temlakos
>>>
>>>
>>> -------------------------------------------------------------------------
>>> ----- Open Source Business Conference (OSBC), March 24-25, 2009, San
>>> Francisco, CA
>>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>>> Enterprise
>>> -Strategies to boost innovation and cut costs with open source
>>> participation
>>> -Receive a $600 discount off the registration fee with the source code:
>>> SFAD
>>> http://p.sf.net/sfu/XcvMzF8H
>>> _______________________________________________
>>> Semediawiki-devel mailing list
>>> Semediawiki-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>>>
>
>
>
|