Hi! I am developing my API extension. It's enumerating revisions, but in a different way (not like in ApiQueryRevisions class). Also, it can optionally create xml dumps via WikiExporter, like API action=query&export&exportnowrap (so I need to change output printer to raw mode sometimes). Because it's enumerating the lists (however not titles) I've choosed "list in non-generator mode" (derived from ApiQueryBase). However, after initial development I've figured out that I cannot change default printer in such case, because it's not being called at all. The reason is explained in following message by Roan Kattouw:
https://bugzilla.wikimedia.org/show_bug.cgi?id=25232
Query submodules can be called in conjunction with other query
submodules
In this case, if your module would switch to a custom printer, the
others would quite likely freak out.
But, I don't need to query in conjunction. Ok, I've derived from ApiBase class (my own API action). Then, it starts to fail on huge amount of generally useful methods, like SQL query building methods (addJoinConds, addWhereRange) and list continuation methods (setContinueEnumParameter), because these are not defined in ApiBase.
I understand that not every ApiBase derived class needs these, but many could have. Why not make inheritance chain like this: ApiBase -> ApiListBase -> ApiQueryBase where ApiListBase would have at least these nice SQL query buliding methods but also the possibility to override the default printer? Why these methods are limited to action=query lists and generators only?
Dmitriy
2010/9/22 Dmitriy Sintsov questpc@rambler.ru:
But, I don't need to query in conjunction. Ok, I've derived from ApiBase class (my own API action). Then, it starts to fail on huge amount of generally useful methods, like SQL query building methods (addJoinConds, addWhereRange) and list continuation methods (setContinueEnumParameter), because these are not defined in ApiBase.
I understand that not every ApiBase derived class needs these, but many could have. Why not make inheritance chain like this: ApiBase -> ApiListBase -> ApiQueryBase where ApiListBase would have at least these nice SQL query buliding methods but also the possibility to override the default printer? Why these methods are limited to action=query lists and generators only?
That's a very good suggestion. Feel free to implement it or, if you can't or don't want to, file a bug requesting it in Bugzilla.
Roan Kattouw (Catrope)
2010/9/22 Roan Kattouw roan.kattouw@gmail.com:
I understand that not every ApiBase derived class needs these, but many could have. Why not make inheritance chain like this: ApiBase -> ApiListBase -> ApiQueryBase
Actually, let's just put that stuff in ApiBase so every module can use it easily. Creating an intermediate class that modules then have to extend serves no purpose.
Roan Kattouw (Catrope)
On Wed, Sep 22, 2010 at 8:17 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
2010/9/22 Roan Kattouw roan.kattouw@gmail.com:
I understand that not every ApiBase derived class needs these, but many could have. Why not make inheritance chain like this: ApiBase -> ApiListBase -> ApiQueryBase
Actually, let's just put that stuff in ApiBase so every module can use it easily. Creating an intermediate class that modules then have to extend serves no purpose.
I disagree. Things that work currently with ApiBase would continue to, and things extending ApiQueryBase wouldn't notice a difference if a few of their methods were moved up a level to a new ApiListBase.
-Chad
2010/9/22 Chad innocentkiller@gmail.com:
I disagree. Things that work currently with ApiBase would continue to, and things extending ApiQueryBase wouldn't notice a difference if a few of their methods were moved up a level to a new ApiListBase.
Moving a few methods from ApiQueryBase up to ApiBase won't break any other ApiBase subclasses. There is no advantage in creating a new class over simply moving this stuff to ApiBase.
Roan Kattouw (Catrope)
On Wed, Sep 22, 2010 at 8:28 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
2010/9/22 Chad innocentkiller@gmail.com:
I disagree. Things that work currently with ApiBase would continue to, and things extending ApiQueryBase wouldn't notice a difference if a few of their methods were moved up a level to a new ApiListBase.
Moving a few methods from ApiQueryBase up to ApiBase won't break any other ApiBase subclasses. There is no advantage in creating a new class over simply moving this stuff to ApiBase.
I thought keeping ApiBase clean of methods most implementations don't need would be a benefit. But I'm willing to concede here :)
-Chad
* Roan Kattouw roan.kattouw@gmail.com [Wed, 22 Sep 2010 14:16:06 +0200]:
ApiBase -> ApiListBase -> ApiQueryBase where ApiListBase would have at least these nice SQL query buliding methods but also the possibility to override the default printer?
Why
these methods are limited to action=query lists and generators only?
That's a very good suggestion. Feel free to implement it or, if you can't or don't want to, file a bug requesting it in Bugzilla.
I probably can implement it, that should be easy. However, 1. I need to have it working with 1.15.x, the customer uses. So I've made a hack, I extend ApiQueryBase instead of ApiBase, but make constructor like ApiBase. Such way, I have both addWhere*() and setContinueEnumParameter() methods working without being forced to use action=query. I've also overrided getDB(), because ApiQueryBase::getDB is unsuitable to ApiBase code (ApiQueryBase::getQuery() and all methods which use ApiQueryBase::getQuery() are also make no sense, thus I've overrided these throwing MWException() ). 2. I don't have core commit access only extension commit access, however I don't feel like MW guru, so I don't even want to request it. I'll probably file a bug. Too bad it will never come back to 1.15.x, though. Dmitriy
2010/9/22 Dmitriy Sintsov questpc@rambler.ru:
- I don't have core commit access only extension commit access, however
I don't feel like MW guru, so I don't even want to request it. I'll probably file a bug.
You can submit patches on Bugzilla too :)
Roan Kattouw (Catrope)
wikitech-l@lists.wikimedia.org