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
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
Hey,
I'm a big fan of the pattern (or at least parts of it), which is the reason I spend quite some effort getting a generic interface into MediaWiki. This is the ORMTable class mentioned by Tyler. Documentation of this class, together with a rationale and some implementation notes can be found here: https://www.mediawiki.org/wiki/Help:ORMTable
I ended up creating this because I found myself having to do the same scaffolding work again and again in different extensions, which was really tedious, and caused inconsistency all over the place. The end result is something very light compared to full object relational mappers while it still manages to take away most of the pains of doing such mappings.
@Tyler can you place any suggestions you have on the talk page? Then we can discuss further without hijacking this tread :)
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
Le 27/08/12 22:53, Chad wrote:
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.
I originally thought we should reuse an existing ORM engine, Jeroen eventually convinced me his code would be easier to maintain for us. He wrote ton of online documentation on mediawiki.org.
ORM would make our code hopefully a bit more concise and avoid us to duplicate logic in all our classes.
We can do the migration as we usually do, by slowly refactoring our code over several releases.
On 08/27/2012 04:53 PM, Chad 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
Could you give an example of how ORM looks like / would look in MW code?
—Victor.
There are some examples linked from the documentation here: https://www.mediawiki.org/wiki/Help:ORMTable
Note that these are not "clean" examples as they contain unrelated code as well.
And of course this is just one example of how you can go about implementing an ORM pattern, while this tread is about the pattern in general.
Sent from my Android phone. On 28 Aug 2012 01:10, "Victor Vasiliev" vasilvv@gmail.com wrote:
On 08/27/2012 04:53 PM, Chad 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/https://gerrit.wikimedia.org/r/#/c/14295/
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
Could you give an example of how ORM looks like / would look in MW code?
—Victor.
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
I was just looking through those classes again.
I think ORMRow is generally OK, since it's mostly a simple CRUD wrapper to deal with some of the busy-work of making data access objects. I don't really get the "summary" (updateSummaries/inSummaryMode) stuff though. I guess the callers/subclasses do most of the summary work there or something.
I'm not really fond of ORMTable/ORMResult. A lot of functions are just wrappers around DB calls that don't really abstract much. Also, singleton() has one table instance per table, making foreign wiki access trickier than with the regular LBFactory/DatabaseBase classes. This kind of stuff makes me hesitant to use the classes (since ORMRow depends on the table class). I guess what I'd really like out of those table classes is the support for base API and Pager classes and the minimum needed for ORMRow (fields/types), with foreign wiki support. I like the idea of getAPIParams() and an API base class for making quick API classes.
The idea of some base classes for CRUD and API/Pager table listings is fine. It can obviously avoid inconsistency among the DAOs. If these classes are called ORM*, I guess that's OK too, as longs as they don't scope creep into a complex system that coupled to everything and hard to change.
-- View this message in context: http://wikimedia.7.n6.nabble.com/Using-ORM-patterns-in-core-tp4984036p498407... Sent from the Wikipedia Developers mailing list archive at Nabble.com.
On Tue, Aug 28, 2012 at 12:12 AM, Aaron Schulz aschulz4587@gmail.com wrote:
The idea of some base classes for CRUD and API/Pager table listings is fine. It can obviously avoid inconsistency among the DAOs. If these classes are called ORM*, I guess that's OK too, as longs as they don't scope creep into a complex system that coupled to everything and hard to change.
This pretty much sums up my position. I'm not wholly opposed to having these for places in which it makes sense (and if extension authors like it, then that's a perfect reason to leave the support in core). My fear, however, is that it begins to creep and we end up totally dependent on ORM. Totally ORM'd databases are scary and don't make sense (eg: gerrit's db).
-Chad
wikitech-l@lists.wikimedia.org