[RFC]: DB-related package migration

[simon-mundy]

Proposed Version

3.0.0

Basic Information

Migrating the abandoned validators, paginator adapters and other DB-related packages so they can belong under Laminas/Db as components.

Background

The following packages were archived/abandoned as part of a larger review to move security-only packages out of the main libraries:

• laminas-paginator-adapter-laminasdb
• laminas-validator - AbstractDB, NoRecordExists, RecordExists

Considerations

All platform specific code will migrate to target axleus/laminas-db-* packages as appropriate.

Proposal(s)

• Separate Validator into Db/Validator and laminas-paginator-adapter-laminasdb into Db/Paginator/Adapter
• Create sub-packages for both
• Consider any additional functionality required for validators (if needed)
• Support for ServiceManager v4

Appendix/Additional Info

No response

[tyrsson]

I would like to propose a new validator along the lines of Validator\DbStoredPassword to validate a stored password. Most common use case would be attaching it to a laminas-form instance.

Another consideration would be a SessionSaveHandler for both laminas-session and mezzio-session.

We might be able to get by with a single package for this along the lines of laminas-db-bridge which would contain Paginator, Validator, Session etc. Although that would create a pretty wild require-dev section for unit/integration test...

[simon-mundy]

I'd rather keep everything separated for the sake of avoiding monolithic packages. There's no reason that Session\SaveHandler can't be a separate package, and it would be quicker and simpler to do.

Re: Validator\DbStoredPassword yes I think that's a fantastic idea. Maybe Validator\PasswordMatch is more in keeping with the existing nature of the Validator family naming convention? Happy to kick that idea around, but the intent is perfect, I would definitely use that a lot. Would the comparison use pre-hashed strings to obscure database logs? Or should we make it so that a native hashing function can be used on the database itself?

[tyrsson]

Currently the only hashing that is supported in my initial code is password_hash. I think since that is the current suggestion by the php team it should be the default, maybe even the only, option. The vast majority of developers should not be trying to build their own bespoke password hashing functions. 99% of the time it does not turn out well.

Just as a side note. We will want to tag pre-release versions of these to provide a transition package just like we are doing for laminas-db.