@Anomie wrote:

In T93873#1149474, @EBernhardson wrote:

Rather than having a single data model that both the API and on page contributions talk to,

Well, there used to be a single data model: SQL database tables. Then people decided they didn't like the existing structure, and added hooks to Special:Contributions to inject their own different stuff on top of the existing structure instead of adding an abstraction layer then.

or api and special page use a shared php class for collecting the information).

That, not the other.

@EBernhardson wrote:

I personally find it crazy that sql is considered the right level of abstraction for serving the exact same information over multiple channels, it all but ensures that code is duplicated in multiple places. But as with all things, intelligent people can disagree.

As to the api vs shared php classes, I also personally find that if we actually want to ensure the same functionality is available over both the API and the standard pages, having the standard page use the API is a great way to accomplish this. It provides not just a hope, but a guarantee that whatever is done in the web interface is doable via the api without duplicating any code.

@EBernhardson wrote:
As to the api vs shared php classes, I also personally find that if we actually want to ensure the same functionality is available over both the API and the standard pages, having the standard page use the API is a great way to accomplish this. It provides not just a hope, but a guarantee that whatever is done in the web interface is doable via the api without duplicating any code.

The consensus seems pretty clearly against that though. For core at least (e.g. this problem) we should probably implement some kind of PHP service/backend controller (people have different terms, basically the place where the database work and logic is done) that both API and Special:Contributions use.

I don't think @Anomie was saying SQL was the right level of abstraction. He said "That, not the other", which I believe means he supports the shared PHP service approach.

I think he was just explaining how we ended up in this boat.

In T88753#1150326, @Mattflaschen wrote:

I don't think @Anomie was saying SQL was the right level of abstraction.

Yeah. SQL was a good level of abstraction when all the contributions were in the 'revision' table, but the ship has sailed on storing Flow information in there.

So now that Flow needs to mix in contributions from its own tables, we need a higher layer of abstraction to do it right, rather than hooks in Special:Contributions that we have now. Which will take someone investigating the requirements of both the special page and the API to design the right interface.