New release again? Yes – and here's why.

[decMuc]

I'm currently in an intensive testing and refactoring phase, which means frequent updates are necessary and intentional. Every module I touch is thoroughly tested and published right away – to ensure stability, security, and transparency for all users.

Versioning explained:
1 – stable base version (originally 1:1 compatible with ThingEngineer)

3 – ongoing improvements (structure, clarity, additional features)

2 – focused patches (security, query validation, bugfixes)

Rather than waiting for large bundled updates, I release in small, verified increments. This prevents insecure code from remaining public and keeps everything traceable.

In the coming days, I’ll also publish my internal test scripts and benchmarks under the “Compare & Tests” section – including:

• injection attempts & edge-case validation

• performance comparisons vs. ThingEngineer's original

• structured examples for real-world usage

Initially designed for full compatibility with ThingEngineer, this project now offers enhanced validation and stricter safety by default – especially in complex SQL scenarios.

Real-world SQL Injection Tests

I've run extensive SQL injection tests against both my own library and the original ThingEngineer class. Surprisingly, most injection attempts didn’t succeed on either — but not because they were blocked. In ThingEngineer's case, they often failed silently or were only stopped by MySQL errors, not the class itself.

For example:
A payload like id = '1; DROP USER' didn’t trigger an exception — it just defaulted to returning id = 1, which is dangerous behavior. My implementation now actively blocks such input with precise type validation and meaningful exceptions.

This is exactly why I push frequent updates: not just to stay ahead of bugs, but to lock down behavior where the original class was too lenient.