Rowcast Laravel Package

Product Decisions This Supports

• Feature scoping — pick the right data layer per feature. Rowcast supports a DTO-first, no-ORM path for row-shaped features: imports/exports, sync jobs, reporting read models, admin tooling, third-party data ingestion. It helps you answer "does this feature need a domain model or just a typed projection of a table?"
• Build vs. buy vs. adopt. Teams routinely hand-roll a column↔property mapper. This is a candidate to adopt instead of maintaining an internal utility — and its scope is deliberately narrow enough (no relations, no identity map, no migrations) that it doesn't become a second framework.
• Incremental architecture roadmap. Adoption is per-table and per-call-site; you can put one write path on Rowcast without committing to a migration. That makes it a low-blast-radius experiment for teams moving off raw PDO toward typed boundaries.
• Legacy/schema-hostile products. Mapping::explicit(...), column/property overrides, and a pluggable NameConverterInterface directly reduce the cost of working with schemas that don't follow conventions (usr_email → email). That's a scoping enabler, not just a nicety.
• Bulk/batch roadmap items. batchInsert / batchUpsert / batchUpdate with automatic chunking against bind-parameter limits (SQLite's 999) inside a single transaction, plus dialect-aware UPSERT, turns "we can't do that efficiently" into "that's a one-sprint item."
• Standardising type handling. TypeConverterRegistry (dates, enums, JSON, bools, plus custom UUID/vo converters) means one decision about where type coercion lives, instead of ad hoc casting scattered per feature.
• Observability decision. onBeforeQuery / onAfterQuery hooks let you decide "log queries via a listener" without adopting a profiler dependency — relevant when scoping APM/profiling work.
• Sourcing/risk decision. With 0 stars and 0 dependents, one real product decision is fork-and-own vs. depend-upstream. That's an ownership and maintenance-budget call, and it should be made explicitly if you adopt.

When to Consider This Package

Consider it when:

• You're on PHP 8.4+ (hard requirement — this is the single biggest adoption gate; most shops are still on 8.2/8.3).
• The team wants explicit DTOs and is comfortable writing SQL or using a fluent builder — i.e., you're not looking for Active Record.
• You need portable UPSERT across MySQL, PostgreSQL, and SQLite, and/or bulk writes that must respect per-driver bind-parameter limits.
• Your schema doesn't match your object model, and you want the mismatch expressed as configuration (Mapping) rather than as glue code.
• You value a small, auditable surface: single package, PHPStan level 9, CI, coverage, docs in English and Russian, an llms.txt, and a fast self-contained test suite (in-memory SQLite). These are real signals of engineering discipline.
• You're framework-agnostic — this is not a Laravel package and doesn't couple you to one.

Look elsewhere when:

• You're already deep in Laravel/Eloquent or Doctrine. Relations, eager loading, identity map, unit of work, migrations, model events, and cast conventions are all out of scope here; running a second data layer usually costs more than it saves.
• You need associations/joins modeled as objects, lazy loading, or a unit of work. You'll end up rebuilding them.
• You need schema migrations — not provided.
• The organisation needs ecosystem support: StackOverflow answers, hiring familiarity, security advisories, an SLA. Zero dependents and zero stars means effectively no community and a bus factor of one.
• You're in a regulated or long-horizon context requiring vendor stability guarantees.
• You need connection pooling, retries, or read/write splitting — Connection is a thin PDO wrapper plus savepoint-based nested transactions.
• You're on drivers outside mysql/pgsql/sqlite expecting dialect-specific behaviour — anything else silently falls back to GenericDialect.

How to Pitch It (Stakeholders)

To executives — one paragraph: Rowcast is a small, single-dependency PHP library that removes hand-written boilerplate for moving data between database rows and typed objects. The value is reduced code and fewer class-of-bug errors (date/timezone, enum, JSON, and boolean coercion) in exactly the features that generate them: bulk imports, exports, sync jobs, and internal tooling. Cost of trying it is low — one composer require, adopted one table at a time, no framework lock-in, no infrastructure change. The risk is maturity, not quality: the codebase shows strong engineering hygiene (CI, PHPStan level 9, coverage, bilingual docs, fast test suite), but it has effectively zero external adoption today.

To engineering: It's a DataMapper over PDO with explicit mapping, a fluent query builder, dialect-aware UPSERT, and batched writes that chunk around bind limits inside one transaction. It gives you typed DTO boundaries without Eloquent/Doctrine, and an extension point for UUIDs, value objects, and custom naming. It will not give you relations, migrations, or a unit of work — if you need those, this is the wrong tool and we should say so now.

The honest risk statement to include in any pitch: 0 stars, 0 dependents, first release cycle, single maintainer. Mitigations: pin exact versions, keep DataMapper behind a thin internal interface so it's swappable, and be prepared to vendor/fork into our namespace if we standardise.

Recommendation and ask: fund a 2–3 day spike on one non-critical read-heavy or bulk-write path, with a go/no-go review after one sprint. Don't standardise org-wide, and don't adopt at all if the team is staying on PHP < 8.4 or is committed to Eloquent/Doctrine.