- What is anourvalar/eloquent-serialize used for?
- It serializes Laravel Eloquent query builders into portable packages and unserializes them later so you can store or pass a preconfigured query with wheres, eager loads, and limits. The intended use case is carrying a query definition across a process boundary, such as building it in a controller and executing it in a queued job. It does not cache query results; the database still runs the query when you call get().
- How do I install anourvalar/eloquent-serialize in a Laravel app?
- Install it with composer require anourvalar/eloquent-serialize. The package needs no service provider configuration, model changes, or migrations, and you call the EloquentSerialize facade directly. That makes initial setup trivial, but you still need to add your own validation and payload envelope around it.
- Which Laravel versions does eloquent-serialize support?
- The package supports Laravel 6 through Laravel 12 according to its README. Check the Composer constraints and test on your exact Laravel minor version before adopting it. Since Eloquent internals change across major versions, run your own round-trip tests rather than assuming support equals compatibility.
- Can I serialize an Eloquent query that uses closures in where or with?
- No, closures such as where(fn($q) => ...) and constrained eager loads with(['x' => fn($q) => ...]) do not round-trip because a builder is not a pure value object. Global scopes, model events, and macro state also may not survive serialization. Restrict serializable queries by construction to a whitelisted subset like where, orderBy, with, and limit, or use a query DTO.
- Is it safe to unserialize Eloquent query packages from untrusted input?
- Treat that as high risk. Confirm whether the package uses PHP serialize/unserialize or JSON; naive unserialize of attacker-influenced strings is a PHP object-injection primitive. Never let payloads cross an untrusted boundary, and if you store them in a database, cache, or queue, sign or encrypt the envelope and validate it before unserializing.
- Does serializing an Eloquent query cache database results or reduce database load?
- No. Serialization saves only the cost of reconstructing the builder, which is microseconds; the database still executes the query when you call get() or paginate(). Do not present this package as a database-load reduction or result-cache mechanism. Use Laravel's cache or a dedicated query cache if you need to avoid database work.
- What happens if my database schema changes after I store serialized queries?
- Serialized queries encode table names, column names, and relationship paths, so a rename or drop can break stored payloads silently. Add a schema version field to your payload envelope and validate compatibility at startup or execution time. Also watch for silent semantic drift, where a stored query written before a global scope change returns different rows without error.
- How should I test serialized Eloquent queries before using them in production?
- Build a test matrix covering closures in where and with, whereIn with large binding arrays, whereHas, nested eager-loaded relationships, pagination, orderByRaw and selectRaw with bindings, soft deletes, global scopes, and enum, date, and Carbon bindings. If more than a small fraction fail to round-trip, the package is not the right primitive for your architecture. Run these tests on the exact Laravel and database versions you deploy.
- Can I use eloquent-serialize to pass a query from a request to a queued job?
- Yes, deferred execution is the strongest fit: author the query where domain context exists, serialize it, and execute it later in a queue worker or scheduled report. However, failures then surface in the worker, which is the worst place to discover an unsupported builder feature. Validate and sign the payload before dispatch and keep the serializable query surface restricted.
- What are safer alternatives to serializing Eloquent query builders?
- For many cases, storing a query criteria DTO or a validated array of filters and rebuilding the query in the job is safer and easier to version than serializing a builder. Named scopes, config-driven query templates, or a documented API endpoint can also replace an internal schema contract. If you do adopt this package, pin the version and wrap it in an abstraction because it is a small, single-maintainer utility.