Dynamodb Dal Bundle Laravel Package

Getting Started

This is a Shopware 6 DAL bundle, not a Laravel package — it swaps Shopware's SQL-backed EntityRepository/EntityDefinition storage for DynamoDB. If you're a Laravel developer, read "Definition" as your model/table schema and "Criteria" as a query builder object; the calling code ($repository->search($criteria, $context)) is unchanged, which is the whole selling point.

1. composer require shopware/dynamodb-dal-bundle:^0.7.1
2. Register the bundle in config/bundles.php (Shopware uses the same file) and clear the container cache.
3. Configure the AWS SDK DynamoDbClient service — region, credentials, and an endpoint override so you can point at dynamodb-local in docker-compose for dev/CI.
4. Pick one entity to move first. High-write, low-relational tables (custom plugin entities, product_visibility, log/telemetry entities) are the sane starting point. Do not start with order/order_line_item.
5. First use case: ship a custom entity through the DynamoDB definition and verify create/search/update round-trip against dynamodb-local.

Where to look first: Resources/config/services.xml for the decorator wiring, the Definition/EntityRepository subclasses under src/, and — as of 0.7.1 — the baseline action, which is now shipped in the package. That action is what creates/updates the DynamoDB table and its secondary indexes, so it's your entry point for provisioning.

Implementation Patterns

Decorator, not rewrite. The intended integration is decorating Shopware's repository services so call sites don't change. Scope the decoration per-entity early; a global decoration on EntityRepository will silently route everything through DynamoDB and that is rarely what you want in one step.

Declare filterable/sortable fields as indexes up front. Criteria filters become Query when they hit an indexed attribute and Scan when they don't. Audit every existing Criteria::addFilter/addSorting on the entity you're migrating and model those attributes into the table definition before you cut over — retrofitting an index later means a table update plus a backfill job.

Use the 0.7.1 baseline action in your deploy pipeline. Wrap it in a console command and run it before app boot on each deploy (and against dynamodb-local in your test bootstrap). Idempotency is the assumption; treat it as your schema migration.

Association loading is explicit. Parent/child loads (order ↔ line items, product ↔ options) that SQL handled with a join now need batching — hydrate children with a single IN-style query on the child table using the parent IDs you just fetched. Do not loop per parent.

Backfill + feature flag. Dual-write from the existing SQL path, backfill historical rows with a queued job, then flip reads behind a config flag. Keep the SQL repository warm for rollback for at least one release cycle.

Testing. dynamodb-local container, a table prefix per test suite, and Shopware's KernelTestCase for integration tests. Assert on Criteria → request translation, not just results; a filter silently degrading to a Scan will still pass a green test.

Gotchas and Tips

• It's not Laravel. No Eloquent, no query builder, no ->paginate(). If you're in a Laravel app, this only makes sense if you're running Shopware alongside it; otherwise you're reimplementing a repository layer yourself.
• 400 KB item limit. Serialized JSON blobs in custom_fields, long description columns, and translation payloads are the usual offenders. Split them into their own table or S3 references rather than learning this in production.
• 100-item / 4 MB transaction limit. Bulk writes of entities with nested associations will hit this. Chunk explicitly; don't rely on the bundle to split for you.
• getTotal() is expensive. Count queries on non-indexed criteria degrade to scans. Cache totals or drop them from list endpoints.
• Consistency. Reads are eventually consistent by default. Cart, inventory, and any read-after-write path should opt into consistent reads.
• Pagination. Anything iterating results must follow LastEvaluatedKey. Silent truncation at 1 MB is the classic first-incident bug.
• 0.7.1 migration note: if you worked around 0.7.0 by vendoring a copy of the baseline action into your own plugin, delete it before upgrading. Duplicate service definitions/schema actions are the likely failure mode.
• Debugging: enable the AWS SDK debug logger and log request IDs; catch ProvisionedThroughputExceededException and back off rather than letting it bubble. If you're on on-demand capacity, watch for throttling during backfills anyway.
• Pin 0.7.*. Pre-1.0, the storage/definition surface is still moving; a minor bump can change container wiring.