Weave Code
Spine Trigonometric Dql Bundle Laravel Package
spine/spine-trigonometric-dql-bundle
Spine Trigonometric DQL Bundle adds trigonometric functions to Doctrine Query Language, letting you use sine, cosine, tangent, and related math operations directly in DQL. Keep calculations database-side and queries cleaner with simple integration into Spine/Doctrine projects.
Set of triginometric functions for DQL in Doctrine.
Frequently asked questions about Spine Trigonometric Dql Bundle
- Is spine/spine-trigonometric-dql-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a Laravel package. Its only real value-add over raw Doctrine is Symfony DI wiring that registers custom DQL functions via a CompilerPass and the doctrine.orm.custom_*_functions config. That wiring is inert in Laravel, where Doctrine is bootstrapped through laravel-doctrine/orm or a manual EntityManager binding with its own configuration path. The portable part is just the set of FunctionNode subclasses implementing the trig functions.
- How do I install this package in a Laravel application?
- There is no Packagist entry confirmed, so you would pull it through a Composer VCS repository pointing at the Bitbucket URL. After that you must suppress Symfony auto-discovery and register each function manually in your Doctrine config. Expect friction: this is not a first-class Laravel dependency and the bundle layer should be treated as documentation rather than runtime code.
- Which trigonometric functions does it add to Doctrine DQL?
- The package provides custom DQL FunctionNode classes for SIN, COS, TAN, COT, ACOS, ASIN and ATAN, plus related math helpers. Each class is typically 30 to 60 lines with parse(), getSql() and platform-specific SQL emission. Because the surface area is so small, copying the classes you need is usually cheaper than adopting the whole package.
- How do I register custom DQL functions when using laravel-doctrine/orm?
- Add the function classes under the doctrine.custom_numeric_functions key in config/doctrine.php, since SIN, COS and the rest return numeric scalars. Use custom_string_functions only for genuinely string-typed return values, which is unlikely here. Then verify the EntityManager picks up the mapping by running a simple DQL query with SIN in a tinker session or test.
- Which Doctrine ORM and DBAL versions does this bundle support?
- That is unresolved from the available information and must be checked before you commit to it. Doctrine 3 changed several AST and FunctionNode contracts, so subclasses written against 2.x may need adjustment. Pin your Doctrine version, run a spike against your target database and assert the generated SQL before relying on it.
- Does this package work with Eloquent?
- No. Eloquent does not use Doctrine Query Language, so the bundle is irrelevant to an Eloquent-based application. If you only need trig in a query, use a raw SQL expression via DB::raw() or compute the value in PHP. Only adopt this if your app already ships Doctrine through laravel-doctrine/orm.
- Which databases are supported and does the generated SQL differ by platform?
- MySQL, PostgreSQL, SQLite and SQL Server all expose these functions, but with subtly different names, casing and return-type behaviour. It is unclear whether the package implements per-platform getSql() or assumes a single vendor. Test against each database you actually deploy to and compare output with a native SQL query.
- Do these trigonometric DQL functions expect radians or degrees, and how are NULLs handled?
- SQL trigonometric functions conventionally operate in radians, and the package does not appear to add any degree conversion layer. NULL propagation follows the database engine, so a NULL argument will generally yield NULL rather than an error. Float precision and rounding also depend on the platform, so verify semantics rather than assuming them.
- Is spine-trigonometric-dql-bundle actively maintained and safe for production?
- Treat it as unmaintained from day one: single author, Bitbucket-only hosting, zero stars and zero dependents. There is no external validation of correctness and any Doctrine major bump would leave the fix with you. Pulling an unvetted VCS dependency into production is disproportionate to roughly 200 lines of logic.
- What is the alternative if I only need SIN or COS inside a Doctrine query?
- Fork the FunctionNode classes into your own namespace, such as app/Doctrine/Functions, preserve any license headers and register them explicitly in the Doctrine config. That removes the dependency entirely and typically takes half a day for a spike plus one to two days to vendor properly. Check the declared license first, because redistribution or vendoring without one requires legal review.
Weaver
How can I help you explore Laravel packages today?