On 24/07/12 22:49, Yaron Koren wrote:
> Hi Markus,
> Semantic Internal Objects still does direct storage of rows in the
> database - that part of the code hasn't changed much from the beginning.
> If there's a better way to store data now, I'd like to know about it.
Yes, there is. The store has full support for internal objects, whatever
direction properties are pointing to. You can create an internal object
using a DIContainer object, and have it link back to its "parent" page.
The small file includes/parserhooks/SMW_Subobject.php shows how this is
The only limitation is that SWMSemanticData can only hold data that has
some relation from the page. So one needs an additional property to
associate the subobject with the page in a forward direction. This does
not affect the other properties (including the one in backward
direction); it just is an additional property to add; you can use the
existing SMW subobject property for this. Basically, the code would look
almost exactly as the code in SMW_Subobject.php, only with slightly
different parsing, an additional backwards link, and another method of
getting a name for the subobject (you can have anonymous subobjects as
well, if you prefer, by starting the subobject name with a "_"; see also
SMW_DV_Record.php line 42ff).
If you change the implementation like this, SIO will work with all SMW
stores without any DB insider knowledge.
> On Tue, Jul 24, 2012 at 4:03 PM, Markus Krötzsch
> <markus@... <mailto:markus@...>>
> Yaron, what in the world do you need the DB keys for? :-) In the
> end, the keys are supposed to mirror how data is stored in DB
> tables. If you just want to store data somehow, there are much
> simpler ways. I thought SIO uses SMW's container feature to avoid
> direct reference to DB internals now? This would also be a useful
> thing to ensure a smooth transition to SMW 1.8 in general.
> Best regards,
> On 24/07/12 14:40, Jeroen De Dauw wrote:
> > Should I keep the SMWCompatibilityHelpers code in SIO for
> now, since
> there's no alternative at the moment?
> There is no reason to do effort changing it to whatever the new
> is since it's going to break in 1.8 anyway. So I'd just stick
> with using
> the compatibility helper class for now.
> Jeroen De Dauw
> Don't panic. Don't be evil.
> WikiWorks · MediaWiki Consulting · http://wikiworks.com