Sqlite3 vs PDO library

[m-lac]

I would like to propose a Sqlite3 implementation into the project. Probably as an option?

• The chip is very unlikely to run any other than Sqlite database
• the chip is constrained for memory resources, so every ms counts in RAM and every KB occupied by library is less ot use for the project.
• I am unsure how large established frameworks will cope with the constraints in other than "demonstration-it-can-be-done" mode, and bespoke framework would sooner or later have to be tailored to the device specifics anyway.

copied are the size parameters from preceding reddit discussion:

Basically negligible - and I just measured it. 
The weight is the SQLite engine (the amalgamation, ~525 KB), 
identical whether you go through PDO or ext/sqlite3: only the wrapper on top changes. 
PDO wrapper (ext/pdo + pdo_sqlite) ~70 KB, ext/sqlite3 ≈ 25 KB switching to ext/sqlite3 drops ~45 KB, 
because you shed the PDO base layer. On a ~3 MB firmware that's ~1.5%. 
(Object-file sizes, pre --gc-sections, so the real .bin delta is a touch smaller.) 
It's more an API choice (PDO = portability, what Laravel/Symfony use; SQLite3 = direct binding) than a size one.

[GianfriAur]

hi @m-lac, as I mentioned to you on Reddit, it's a great idea.

As for how to do it, the adaptation is fairly straightforward if you need to extensively rewrite a part of the library—like this, for example: components/php/patches/sqlite/0001-fatfs-lseek-past-eof.patch

in our case this path already covers the new use case (I think),

The configuration I envision in a php-esp32.config.toml project file is:

name = "my-amazing-project"

[extensions.sqlite] # ~525 KB
enabled = true
type = "pdo-sqlite" # default : "pdo-sqlite", allowed : "pdo-sqlite" (ext/pdo + pdo_sqlite) or "sqlite3" (ext/sqlite3)

Do you consider this an elegant and worthwhile solution?

[m-lac]

Lovely!

[GianfriAur]

hi @m-lac, as i promise you now is possible use only ext/sqlite3 as we previously discussed