Add QBMapper::findById

[ChristophWurst]

As of Nextcloud 24 / #31513 it is a requirement that all tables have a primary
key. This allows us to make an assumption about what a findById looks
like.

This is a kind-of breaking change due to the fragile base class
problem. Therefore we need to give app devs a heads-up before this is
added. E.g. by telling them to rename their existing findById methods if
they want to support wider ranges of Nextcloud or drop theirs in favor
of the new base class method.

I would plan to add this only for Nextcloud 25.

In the same sense we could also add deleteById in addition to delete so that rows can be deleted without a prior retrieval.

Todo

• Implementation
• Documentation

[juliusknorr]

We only enforce having a primary key but not the column name id so far and there are a couple of cases where different primary column names are used. Also some tables may use multiple columns as primary key. Not sure if there is a good way to safeguard that, but at least we should document that this would only apply to columns that follow the id naming.

[nickvergessen]

In the same sense we could also add deleteById in addition to delete so that rows can be deleted without a prior retrieval.

This is something we have to fix one way or the other. I just got rid of O(n) selects in user status by adding a method that works without the object and only on the id.

Otherwise what julius said

[ChristophWurst]

Alright, that is a bummer. I'll think about it then :)

[miaulalala]

Can we not take a page out of Laravel's book and allow a custom property that can overwrite the default primary key id column?

For example: https://codeanddeploy.com/blog/laravel/change-primary-key-and-timestamps-in-laravel-8

[nickvergessen]

Could also call it "findByPrimaryKey" and then the entity/mapper has a field which specifies which fields are the PK and selects/deletes by that?

[ChristophWurst]

Can we not take a page out of Laravel's book and allow a custom property that can overwrite the default primary key id column?

Yes and no. Laravel makes the assumption that you have a singular key, while we also allow composite keys. Factoring in that it's not only about the column name but arity and type, I'd rather leave that to the developers.

I guess we should rather have an extension of the qb mapper that only works with singular artificial integer primary keys aka the typical id.

I'll do that another time.