I'm currently working on v2 (and for anyone reading in the future, I have not released it at the time of writing).

I noticed that some of the AI models were giving me loads of hallucinations when it came to database interaction. So, I have just spent the entire day rewriting all the methods for database interaction. The process by which this was written involved going through six AI models and asking all of them to effectively judge which syntax is the most 'guessable' and therefore the most AI friendly. It took ages.

The code below is what they collectively came up with, but I want to run it past you first to make sure it's not bonkers. Any feedback would be welcome:

https://github.com/trongate/Trongate-v2-Dev/blob/main/modules/db/Db.php

What z.ai says:

First Set: 35/100
Arguments (-40 points): The order of arguments (order_by before table, limit in the middle) is illogical. Without documentation, it is almost impossible to guess the correct sequence.
Hidden Behavior (-15 points): The reliance on the URL to determine the table name is "magic" behavior that a developer would never predict just by looking at the method name.
Naming (-10 points): Distinctions like get_where vs get_one_where vs get_where_custom are verbose and easily confused without a manual.

Second Set: 95/100
Arguments (+5 points): The use of the $options array for non-essential details (like limit/offset) makes the code readable and self-documenting. You don't have to memorize positions.
Explicitness (+5 points): Requiring the $table name as the first argument makes the context crystal clear.
Consistency (+5 points): The naming convention (get, get_by_id, update, update_where) is predictable and follows standard industry patterns.
Deduction (-5 points): While very high, the user still has to guess the keys inside the $options array (e.g., is it 'limit' or 'max'?), though this is much easier than guessing argument positions.

get(…), get_by_id(…), get_where(…) could be reduced to simply get(DB_Query|string $query)

// query builder pattern
class DB_Query implements \Stringable {
public array $wheres = [];

function __construct(
public string $table,
public string $select = ‘*’
) {}

function where(string $column, mixed $value, string $operator = “”) {
$this->wheres[] = compact(‘column’, ‘operator’, ‘value’);
}

// order_by, limit, etc methods

function ___toString() {
// compile sql string
return $sql_string;
}
}

Thanks!

Consider this:



Now, compare to this:



Both are valid.

Which one do you think is the most intuitive?

EDIT: On second thoughts, it's kind of irrelevant. The first one returns an object or false. The second one returns an array. They're different.

The method names and syntax look intuitive to me.
I think it's a step in the right direction.

Thanks. To be clear, the goal is not to make the code small - but to make it guessable.

Fellas,
Forgive me for chiming in, but after 30+ years coding DB2/SQL integrated into COBOL on the backend, plus with Command Level CICS on the frontend, if you didn't know how to read and write SQL, you wouldn't have a job.
I'm not sure what kind of programmers need to have their SQL written for them.

Can you please explain to me, what is intuitive about either of these two statements?
What will a "get_one_where" statement look like with a compound "where" clause? For instance...
username= 'Rambo" and first_name="John"

At least the "get()" provides an array of key/value pairs, providing us with a compound list of parameters, but we still need to know which logical operators they are to be connected with ("and", "not", "or", or some combination therein).

Hey,
If I'm out of line, just say so. It happens sometimes when I overstep.

I’ve just realised, Charles - I think you might have been making this point:

“Why bother with all that horseradish when we can just write SQL?”

If that is the point you were making, then you’re officially Jedi level and you are fifty steps ahead of me.

Hey,

This is DC writing on my phone from my mum's house.

Charles is right. We need extreme simplification.

That was indeed me. I think Charles might be onto something here. Why bother with all those methods when we can just have a few that can handle everything?

It's a really bold approach but to me that makes sense!

Is that what you were getting at, Charles?