- What is laravel-sql-function-repository used for?
- It provides a repository pattern wrapper for calling PostgreSQL stored functions and procedures from Laravel. You define repository classes, and method calls translate into parameterized SELECT * FROM function_name(?, ?) invocations through Laravel's DB layer. It is a convenience abstraction, not an ORM, query builder, or persistence layer.
- How do I install michael-rubel/laravel-sql-function-repository?
- Install it with Composer using composer require michael-rubel/laravel-sql-function-repository. There is no significant service provider or configuration surface; you extend the base repository and inject it through Laravel's container. Confirm version constraints resolve against your exact Laravel and PHP versions before rollout.
- Does it support Laravel 10, 11, or 12?
- Release 1.1.2 added Laravel 10 support via a pull request, but the package has a very small maintenance footprint. Check the composer.json constraints for laravel/framework, illuminate/*, and php against your exact stack. Laravel 11 and Laravel 12 compatibility should not be assumed without verification.
- Do I need PostgreSQL to use this package?
- Yes. It is built specifically for PostgreSQL stored functions and procedures, so it will not work with SQLite, MySQL, or other engines that lack compatible function invocation semantics. This also means SQLite-based test suites are not a fit unless you abstract or mock the database layer.
- Can I test repositories that call database functions?
- Because the package is a thin wrapper over Laravel's DB layer, testing depends on how you isolate database calls. You can mock the repository interface or use a PostgreSQL test database with seeded functions. The package does not ship testing utilities, so plan for integration tests against a real PostgreSQL instance.
- How does it handle parameter binding and SQL injection?
- Calls are made through Laravel's DB layer with bound parameters, so values are passed as placeholders rather than interpolated into SQL. That is safer than scattered raw queries, but function names still need to be controlled by your code because identifiers are not parameter-bindable. Review repository methods to keep dynamic identifiers out of user input.
- Is michael-rubel/laravel-sql-function-repository maintained?
- The 1.1.2 release shows nominal maintenance activity after a long gap, but adoption is low, with few stars and no known dependents. Treat it as alive but not fully de-risked for critical production use. Verify current archived status, SCA policy compliance, and maintainer responsiveness before adopting.
- What are alternatives to using this package?
- You can call PostgreSQL functions directly with Laravel's DB::select or DB::statement, or wrap them in your own small repository classes. Because the package is only a few hundred lines of commodity code, forking or reimplementing the pattern internally is low cost. ORMs and query builders do not replace it because they primarily target tables, not stored function invocation.
- When should I avoid this package in a Laravel app?
- Avoid it if your team keeps business logic in PHP and treats the database as dumb storage, because the package assumes logic lives in database functions. Also avoid it if you use SQLite for testing, need multi-engine portability, or cannot accept PostgreSQL coupling. Architectural fit matters more than the package's small code surface.
- What is the vendor lock-in risk with this package?
- Low. The package is a thin convenience wrapper of a few hundred lines, so escape cost is measured in hours rather than weeks. You can fork it, vendor it, or reimplement the repository pattern internally without a meaningful rewrite. The bigger lock-in is the PostgreSQL function lifecycle you build around it.