- Is laracache a caching layer for Laravel, or a database driver?
- Despite the name, laracache is not a Laravel cache-store driver. "Cache" refers to InterSystems Cache (now part of InterSystems IRIS), the post-relational database the package connects to. It provides an ODBC-based data source so your Laravel app can query that database through Laravel's database layer. If you were looking for a Redis/Memcached-style cache store, this is not that package.
- How do I install jeandormehl/laracache in a Laravel application?
- Install it with Composer using composer require jeandormehl/laracache. The package registers a service provider through Laravel's package auto-discovery, so no manual provider entry is normally needed. Publish the bundled configuration with php artisan vendor:publish and select the package's tag from the list. Make sure the PHP odbc extension is enabled in the same PHP runtime that serves your application.
- Which PHP and Laravel versions does laracache support?
- Support is defined entirely by the php and illuminate/* constraints in the package's composer.json, so read the file on the exact tag you intend to install rather than trusting the README alone. Version 5.0.0 added PHP 8.5 support, which in practice usually means a raised minimum PHP floor and dropped older illuminate/* ranges. If your application runs PHP 8.2 to 8.4, pin to ^4.0 until the constraints have been audited. A caret constraint alone is not enough protection against an unattended composer update pulling a major.
- What ODBC prerequisites does laracache need on the server?
- You need the InterSystems ODBC client driver installed on every host that runs the application, plus PHP's odbc extension compiled or enabled. The driver typically requires either a configured DSN or a full DSN-less connection string including host, port, and namespace. Container images must bake the driver in at build time, since installing it at boot is slow and fragile. Confirm the driver architecture (32-bit versus 64-bit) matches your PHP build.
- How do I configure the InterSystems Cache connection in Laravel?
- After publishing the config, you register a connection entry alongside your existing MySQL or Postgres connections and keep credentials in environment variables rather than in source control. The host, port, namespace, and ODBC driver details are what usually differ between environments, so template them per environment. Keep the connection name generic enough that swapping the underlying driver later does not require editing query code. Commit a working example in your .env.example so new developers do not have to reverse-engineer the setup.
- Should I upgrade to laracache 5.0.0 now, or stay on 4.x?
- Stay on ^4.0 until you have diffed v4.0.0 against v5.0.0 and read the committed composer.json on the 5.0.0 tag. A major bump whose changelog only says "Support PHP 8.5" is almost always a raised PHP floor that cascades into a higher illuminate/support requirement, which can force a Laravel upgrade you were not planning. Validate 5.0.0 in a throwaway Laravel skeleton on PHP 8.5 before touching production. Never batch a database-driver upgrade with a framework upgrade unless you have to.
- How do I test laracache without a production InterSystems Cache server?
- ODBC talks to a real server, so meaningful tests need either a dedicated InterSystems instance or a container-based test environment with a seeded namespace. Unit tests can mock the connection layer, but they will not catch driver-level issues such as type mapping or encoding problems. Keep integration tests in a separate suite so the default phpunit or Pest run stays fast and does not fail on machines without the ODBC driver. Seed and tear down test data deterministically, since a shared test namespace will otherwise leak state between runs.
- Does laracache work with Eloquent, the query builder, and migrations?
- Reads through the query builder generally work because they travel over the standard Laravel database connection contract, and simple Eloquent models can be mapped onto it. Schema tooling is the weak spot: Laravel's migration grammar targets mainstream SQL dialects and InterSystems DDL differs, so do not assume schema builder calls translate cleanly. Treat the schema as owned externally and keep your Laravel-side models read-mostly where possible. Verify auto-increment, boolean, and date handling explicitly, because those are the usual culprits for silent mismatches.
- What are the alternatives to laracache for connecting Laravel to InterSystems Cache?
- The lowest-level option is PHP's native odbc or PDO_ODBC extension wrapped in your own small connector, which removes a third-party dependency but costs you maintenance. Doctrine DBAL with a custom driver is viable if you already depend on Doctrine. For read-heavy use cases, exposing InterSystems data through a REST or API layer and caching the responses in Redis often beats a direct ODBC connection on latency and blast radius. Choose the direct driver only when you genuinely need live transactional reads.
- Who maintains laracache, and how risky is the single-maintainer release cadence?
- It is a single-maintainer project that ships majors quickly, so plan for the bus factor rather than assuming long-term support. There is no published LTS policy, which means 4.x patch availability after 5.0.0 is a question you should ask upstream or answer by forking. Pin an explicit caret-plus-floor version in composer.json and review the diff before any major. If the package becomes load-bearing for query contracts, keep a fork path open and document the connection config so a swap stays cheap.