skyfox/propel-bundle
Symfony bundle that integrates the Propel ORM, letting you define models in schema files, generate PHP classes, and query data through Propel's fluent API, with configuration, service wiring, and console tooling built into the Symfony framework.
This is a Symfony2/Symfony3-era integration of Propel ORM — the fork is thin (7 stars, 0 dependents), so treat it as a drop-in replacement for propel/propel-bundle on legacy projects rather than a modern choice. Symfony 4+ Flex apps will fight you on bundle registration, and PHP 8 compat is not guaranteed by the fork itself (Propel 2 runtime is the real dependency).
Version alignment matters. The 5.1.0 release is the stable cut of the 5.1 branch, and it targets the Propel 2.0.0-beta2 runtime. That means the bundle's own version is "stable" but the ORM underneath is still a beta — pin both sides explicitly:
"require": {
"skyfox/propel-bundle": "5.1.*",
"propel/propel": "2.0.0-beta2"
}
Do not let Composer float propel/propel to ^2.0 — beta3/beta4 changed generator output in ways the 5.1 branch does not track. If you're upgrading from 5.0, this is a stable line release (no breaking changes announced), so composer update skyfox/propel-bundle --with-dependencies and a rebuild is normally sufficient — but diff your generated Map/ classes before committing.
Minimal setup:
composer require skyfox/propel-bundle:5.1.* propel/propel:2.0.0-beta2 — if it isn't on Packagist anymore, add the VCS repo or a path repository entry. Also add the symfony/console version your app already uses; the bundle assumes it.
Register the bundle. On Symfony 2/3 that's new SkyFox\PropelBundle\PropelBundle(), in AppKernel.php. Under Flex it's config/bundles.php.
Create config/propel.yaml (or app/config/config.yml in Symfony 2) with at minimum:
propel:
paths:
schema: Resources/config/
dbal:
connections:
default:
adapter: mysql
user: root
password: ~
dsn: mysql:host=127.0.0.1;dbname=app
classname: Propel\Runtime\Connection\DebugPDOConnection
Drop your schema.xml (Propel XML schema, not Doctrine) into the configured schema path.
Run bin/console propel:model:build (or propel:build which chains model + sql + form). You should see generated Model/, Model/Map/, and possibly Form/ classes in src/AppBundle/Resources/... or src/Model/.
Verify with bin/console propel:migration:status (uses Phing internally under the hood — no Phing binary needed, the bundle shells out via Symfony process).
First use case to prove it works end-to-end: a tiny Author schema, build models, wire AuthorQuery into a controller via ->findPk().
ActiveRecord, not DataMapper. Unlike Doctrine, Propel models are the entities and the repositories. Day-to-day you'll call static methods on XQuery:
$authors = AuthorQuery::create()
->filterByIsActive(true)
->joinWith('Book')
->orderByLastName()
->paginate($page, 20);
No EntityManager. If you're used to $this->getDoctrine()->getRepository(...), you'll be writing AuthorQuery::create() directly. There is no bundle-level service wiring for query classes — they autoload from the generated classmap, which is why propel:model:build must run after every schema change.
Build workflow — the commands you live in on this bundle:
propel:build — meta-command, runs model:build, sql:build, and any form/filter generation.propel:model:build — regenerate Model/ and Model/Map/ after schema edits. Always commit the generated Map/ classes; they carry column metadata that queries rely on.propel:migration:diff — compares schema vs. live DB and emits a migration class under migrations/.propel:migration:migrate — applies the pending diffs.propel:sql:insert — seeds from fixtures/*.yml in the configured fixtures path.propel:schema:validate — catches XML typos before you waste a build cycle.Runtime API surface is the beta's, not the bundle's. Everything you actually call (ModelCriteria, Propel::getConnection(), the behavior system, Collection semantics) comes from propel/propel 2.0.0-beta2. When a query builder method behaves oddly, check the beta's source/CHANGELOG before blaming the bundle — a 5.1.0 bug report against the bundle is usually a runtime issue the fork simply mirrors.
Service usage in controllers. The bundle registers a propel service and a Propel\Runtime\ServiceContainer\StandardServiceContainer alias. Most teams bypass it and instantiate query classes statically. For non-static needs (custom repository helpers, transaction wrappers) inject propel or the low-level Propel\Runtime\Connection\ConnectionManagerInterface.
Transactions:
$con = \Propel\Runtime\Propel::getConnection();
$con->beginTransaction();
try {
$author->save($con);
$book->save($con);
$con->commit();
} catch (\Exception $e) {
$con->rollBack();
throw $e;
}
The ActiveRecord save does not auto-thread the connection through related objects unless you pass $con to each save() — this is a common source of partial writes.
Forms. If you enable the form generation (propel:build with form config), the bundle emits XxxType classes in Form/Type/ extending BaseXxxType. They wire to the generated XxxForm base class, not Symfony's default form model. Register them as services and use them as normal FormType. Note the generated form classes come from the 2.0.0-beta2 generator — regenerating after any runtime bump will churn these files.
Schema-first over migration-first. Propel's philosophy is that schema.xml is the truth — migrations are generated from diffs, never hand-written (you can, but the next migration:diff will lie). Keep schema split by bundle: src/AppBundle/Resources/config/schema.xml gets aggregated automatically when paths.schema points at the bundle directory.
Fixtures. Use propel:sql:insert --type=yaml --dir=src/AppBundle/Resources/fixtures. Propel's YAML fixture loader is much less capable than Alice's — no faker, no relational references by name; you must set explicit IDs and foreign keys.
The fork is stale and quiet — and the runtime is beta. 7 stars and 0 dependents means you are the QA team, and 5.1.0 pins you to 2.0.0-beta2, which will never be patched for upstream CVEs. Pin skyfox/propel-bundle to a commit hash and propel/propel to 2.0.0-beta2 exactly in composer — not a version range. If the fork dies on Packagist, your rebuilds break. Consider vendoring it or switching to propel/propel-bundle if it still supports your Symfony version; the APIs are near-identical.
Treat 5.1 as a frozen line. "Stable version of branch 5.1 supporting branch 2.0.0-beta2" is a maintenance/branch-stabilisation release, not a feature release. Plan for no further movement: fork the bundle into src/ or a packages/ path repo if you need fixes, and record the exact upstream commit the fork was taken from so a future migration to Doctrine is auditable.
Schema autoloading is classmap-based. After propel:model:build, composer dump-autoload won't help — the bundle registers Propel's own ClassLoader. In dev you'll want propel.runtime.conf.autoload_classmap disabled so new files are picked up without a rebuild; in prod keep it enabled for speed.
propel.yaml vs config.yml differs by Symfony version. Symfony 2/3 users put config in app/config/config.yml under the propel: key. Symfony 3.3+ expects config/propel.yaml via prependExtension. Mixing them silently ignores your DSN — check bin/console debug:config propel (Flex) if connections look empty.
Diffs are destructive on column renames. propel:migration:diff treats a rename as drop + add, which nukes data. Either rename in two migrations (add new, migrate data, drop old) or edit the generated migration class before applying. The bundle's diff generator is not rename-aware.
No Doctrine-style annotations. Everything is schema driven. If you try to add a property to a generated model directly, it disappears on the next model:build. Custom logic belongs in the Base classes you're supposed to subclass — but the build overwrites those too unless you disable propel.generator.model.auto_package or use the --no-rebuild-classes flag when supported. Safest pattern: put custom methods on a hand-written class in src/Model/ that extends \Propel\Runtime\ActiveRecord\ActiveRecordInterface and use Map/ metadata, or use Propel's behavior system in the schema.
Debugging SQL. Set classname: Propel\Runtime\Connection\DebugPDOConnection in the connection block (as in the Getting Started snippet) to get a propel.log populated — it's the only way to see what the query builder actually emitted, since there's no app.log integration. Watch that file for double-prefixed table names when schema package overrides go wrong.
Phing dependency sneaks in. Many propel:* commands delegate to Phing tasks from propel/propel-bundle's Resources/php/ scripts. If commands fail with "task not found," it's usually a missing propel/generator (matched to the beta2 version) rather than your config.
Symfony 4+ incompatibility. The bundle's service definitions use deprecated patterns (setFactoryService, setFactoryMethod string calls). Under Flex you'll often need to alias the kernel container or the extension silently no-ops. Budget an afternoon debugging Configuration if propel:model:build outputs nothing.
Extension points worth knowing: override Configuration::getConfigTreeBuilder() if you're forking, use the propel.connection.* event tags for observability, and hook pre_propel_build / post_model_build events to lint generated files. The Phing listeners are the least-fragile extension point — everything else depends on the generated class layout.
How can I help you explore Laravel packages today?