From what I can tell, MediaWiki is trying more and more to reduce code
re-use and move toward an easy MVC design, where the models are handled by ORM, the controllers are either Actions or SpecialPages, and the views are handled by Skin/Message/HTMLForm. And while ORMTable and FormAction, etc. are not used everywhere in the code, I believe this is a good direction to move in, primarily because it makes everything easier on developers. For example, I am making an extension for SSL authentication (because the current one is pretty dated), and I used FormSpecialPage with ORM to make the entire extension, and development was so easy it was beautiful. What would have otherwise been implemented using custom DatabaseBase calls and random functions is now made vastly simpler with standard interfaces.
Also, I believe in MediaWiki's case ORM is the right way to go rather than the alternative raw SQL method. I say this because the primary reason people argue against ORM is because you have more freedom over the database and can focus on the data rather than the functionality. In MediaWiki, because of various compatibility reasons, there's only so much SQL we can use. For example, stored procedures are thrown out the window because Sqlite doesn't support them. Because of this limitation, the usual disadvantages of ORM do not apply. And while I'm sure an argument could still be made against ORM, I think the arguments in favor are a lot stronger.
On that note, I'd just like to say that our ORM interfaces still have room for improvement. It would be good to have ORM handle instantiation of various internal types without bothering the end developer about it. For example, if ORMRow could automatically make User objects or Revision objects, etc from a row result where the indicated field is a reference to such an object. Also, there are weird quirks, such as the fact that ORMRow forces you to have an "id" field in your table, even if that doesn't necessarily apply to the model you are developing. Another quirk is the fact that fallbacks don't exist. The User object, for example, will try and load from the database or session, but if it doesn't find anything, it will default to an anonymous user. ORMTable, however, will return false when calling selectRow() rather than creating a default object, forcing the outer layers of code to load defaults manually. The easy way to fix this would be to change loadFields() so that rather than use the ID, just use any indexed fields in the object to load the fields. That way you can use newRow() to load defaults and then call loadFields() in an attempt to get from the database.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Mon, Aug 27, 2012 at 4:53 PM, Chad innocentkiller@gmail.com wrote:
Hi,
It's recently come up in some of the Wikidata changes proposed to core to start using some ORM-like interfaces for accessing this data[0]. Since we don't use ORM-style access anywhere else in core, I figured it warranted some wider discussion before we begin introducing the pattern.
Personally, I'm a big fan of consistency and since we don't use ORM anywhere else, I'm hesitant to begin using a new design pattern here (and I'm not entirely convinced why it's *needed*). On a more philosophical level, I personally don't like ORM because I think it needlessly abstracts data access in a more confusing way--but my personal feelings can be forgotten if people think this actually makes more sense.
However, I may be in the minority here, and my fears are unfounded. I would love some feedback from everyone about whether ORM in the sites code (and more generally, in core) is a good idea.
Thoughts?
-Chad
[0] https://gerrit.wikimedia.org/r/#/c/14295/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l