- How do I install telkins/laravel-dag-manager in a Laravel app?
- Install it with Composer, publish the package config and migrations, define your vertex and edge models, then run the migrations. The integration is mechanically simple: migrations, Eloquent models, and config, with no runtime daemon or external service. If you copy a custom edge model example from older docs, audit the namespace because v5.0.0 fixed an example namespace issue.
- Does laravel-dag-manager support Laravel 13 and PHP 8.5?
- The v5.0.0 release notes add Laravel 13 and PHP 8.5 support. That generally means the v5 line targets the newest Laravel and PHP versions, so adopting it may force a stack-wide upgrade. For older Laravel or PHP versions, check the package composer.json constraints and use the matching package major rather than assuming backward support.
- Is telkins/laravel-dag-manager a workflow engine or job orchestrator?
- It is primarily a SQL-based persistence and traversal library for directed acyclic graphs, not a full workflow engine. It models vertices and edges and supports dependency-shaped data, but it does not schedule, execute, retry, or observe nodes. Pair it with Laravel's queue and job layer, or a dedicated orchestrator, if you need execution semantics.
- What changed in v5.0.0 and is it a breaking upgrade?
- The available v5.0.0 notes list only two merged changes: a namespace fix in the custom DAG edge model example and added Laravel 13 / PHP 8.5 support. No new features are documented. Because it is a major-version bump with a thin changelog, review UPGRADE.md, CHANGELOG.md, and composer.json constraints before upgrading; the exact breaking change is not verified from the release notes alone.
- Should I extend the Vertex and Edge models or use them directly?
- You can either extend the package's base Vertex and Edge models or use them directly, depending on how much domain behavior you need. Extending is common when you need custom relationships, scopes, or table names. If you copied the custom DAG edge model example before v5.0.0, audit the namespace because the example was corrected in that release.
- What Laravel use cases fit a SQL-based DAG package?
- Good fits are graph-shaped, read- or traverse-heavy domains such as approval chains, workflow or dependency definitions, org and category hierarchies, prerequisite modelling, and lineage tracking. It is a poor fit for highly dynamic graphs with high write volume or traversal on a hot request path. It also is not a substitute for a real workflow orchestrator when execution, retries, and observability are required.
- How does the package handle ancestor/descendant traversal and cycle prevention?
- Ancestor and descendant queries plus cycle prevention are core value of the package, and they are the parts most worth testing explicitly in your application. The v5.0.0 notes do not document semantic changes to traversal or cycle detection, but a major-version and dependency bump can still produce subtle, data-dependent regressions. Add regression tests for depth limits, cycles, and expected ancestor/descendant sets.
- What performance issues should I expect with deep DAGs in production?
- There is no verified published ceiling for deep graphs, so benchmark with production-like depth and branching before relying on it. Traversal may use recursive CTEs or iterative queries, and edge-table indexes are critical for latency. Avoid running heavy traversals on hot request paths; cache results or precompute where possible.
- How should I test a DAG implementation in Laravel?
- Use Laravel's test database and migrations, then create vertices and edges through factories or model helpers. Assert expected ancestor and descendant sets, cycle rejection, and depth behavior rather than only checking that records exist. Include upgrade regression tests because traversal regressions are subtle and data-dependent.
- Is telkins/laravel-dag-manager actively maintained, and what are alternatives?
- The v5.0.0 release was community-contributed by two first-time contributors, including the framework-support change, which is healthy but concentrates risk. There is no maintainer-authored changelog or stated deprecation policy in the available notes, so assess bus factor and security-review ownership before adopting it. Alternatives depend on your need: closure tables or recursive CTEs for graph persistence, or a dedicated workflow orchestrator for execution-heavy pipelines.