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(a)gmail.com
On Mon, Aug 27, 2012 at 4:53 PM, Chad <innocentkiller(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l