On Freitag, 1. Januar 2010, Yaron Koren wrote: > Hi, > > Perhaps it would make sense to do a quick release of the software as it > currently is, as version 1.4.4 or some such, on the chance that the > refactoring will break one or more extensions?
I don't expect it to break extensions since the DB layout is unchanged so far. There is a small difference in how multi-valued properties are declared and stored, so users will have to update the property pages in these cases, and extensions will be affected if they read n-ary data directly from the DB tables. I can't imagine that any extension is doing this. The datavalue class for storing n-ary data will also change, so code that does something special with n-aries may need some small adjustments. The datavalue API will only be extended. Even though many methods might then become obsolete, they will only be deprecated for now and not be completely removed until SMW 1.6. The only minor incompatibility there is that the format of getDBkeys() for SMWNumberValue and its derivatives changes. But I guess all extensions that read this data do use other functions anyway. Most changes are really inside the SQLStore2 implementation which will become much more flexible and less case-based than it is now. It will then be able to manage data of arbitrary types, known or unknown, without referring to idiosyncratic APIs for each datavalue. -- Markus > > -Yaron > > > On Fri, Jan 1, 2010 at 1:55 PM, Markus Krötzsch < > > mar...@semantic-mediawiki.org> wrote: > > This is just to inform all developers of SMW that I am about to do a > > major refactoring of parts of SMW (long time I did the last one ;-). In > > particular, > > I am about to rewrite SQLStore2 with the goal of making it more readable > > (i.e. > > reviewable) and more elegant/powerful (it won't become pretty, but > > certainly > > less ugly). En route, there will be major improvements for container > > objects > > (internal objects, n-aries, whatever), and for the datatype API in > > general. > > > > Since I can only commit this change as a whole, I would appreciate if > > nobody > > implements changes in SMW parts related to datavalues, types, or storage > > within the next couple of days. Other parts are unaffected (special > > pages, parsing, maintenance, ...). > > > > -- Markus > > > > -- > > Markus Krötzsch <mar...@semantic-mediawiki.org> > > * Personal page: http://korrekt.org > > * Semantic MediaWiki: http://semantic-mediawiki.org > > * Semantic Web textbook: http://semantic-web-book.org > > -- > > > > > > ------------------------------------------------------------------------- > >----- This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support A > > streamlined, 14 day to market process makes app distribution fast and > > easy > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > _______________________________________________ > > Semediawiki-devel mailing list > > Semediawiki-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > -- Markus Krötzsch <mar...@semantic-mediawiki.org> * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org --
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
