Consistent DB enum function

[homersimpsons]

Fixes #1813

Description of the Change
Make all DB enum functions consistent

About the following requirement from the task:

In addition a third argument for limit clauses should be added to the basic functions and the class implementations

Should I just update the DbConn::enum and DbConn::enum_fields?

Release Notes
N/A

[homersimpsons]

I added the typing. If we target recent php versions I can just add it directly in the function signature (except for the generic return).

[homersimpsons]

The case was incorrect. PHP is case-insensitive but it is better to use the correct casing.

[homersimpsons]

I would like to split this file to have 1 file per class for OOP. I'm not sure that this is possible with the current setup though.

[homersimpsons]

This is the only occurence of $where_clause=null, should I keep it? Or should I check for usages?

[homersimpsons]

Would it make sense to have this function in a trait?

Copilot wasn't able to review any files in this pull request.

Files not reviewed (5)

• html/inc/boinc_db.inc: Language not supported
• html/inc/db_conn.inc: Language not supported
• html/ops/create_forums.php: Language not supported
• html/user/get_project_config.php: Language not supported
• html/user/server_status.php: Language not supported

[AenBleidd]

@davidpanderson, please review

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 10.73%. Comparing base (c67393e) to head (6c38fbe).
Report is 10 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##             master    #5952   +/-   ##
=========================================
  Coverage     10.73%   10.73%           
  Complexity     1068     1068           
=========================================
  Files           280      280           
  Lines         36619    36619           
  Branches       8489     8489           
=========================================
  Hits           3930     3930           
  Misses        32300    32300           
  Partials        389      389           

[davidpanderson]

There's a better way to do the DB API, but a this point there's no
reason to change what we have.
Let's not change the coding style.

[homersimpsons]

There's a better way to do the DB API, but a this point there's no reason to change what we have. Let's not change the coding style.

Can you update your vision on #1813? I may be able to tackle this.

[davidpanderson]

It's possible to use inheritance so that the table-specific classes (BoincUser etc.)
share the same enum(), lookup() etc. functions.
This would greatly shrink the code.
However, our current policy with the PHP code is: if it ain't broken don't fix it.

Something that would be worth doing: make sure that SQL injection attacks are impossible.
The DB APIs are often called with arguments that are user-supplied: GET/POST args and cookies.
String args are generally 'sanitized' with escape_string(), but:

• numeric args should be sanitized too, e.g. with intval()
• right now it's vague whether sanitization is the job of the caller or the API;
  this should be nailed down.

I can create an issue if you'd like.

[homersimpsons]

right now it's vague whether sanitization is the job of the caller or the API;

If we take example from PDO, DBAL and Eloquent they all favor parameterized queries. So it is the responsibility of the caller to use parameters and the API guarantee that those cannot be used as SQL injection.
If I recall correctly this also has the advantages that some SQL engine will be able to parse / analyse the SQL query only once instead of doing it every time there is a parameter that changes.