Strategies for purely promoting Propel models in Symfony2?

Question

I want to do this:

// Model class namespace Bookshop\Inventory\Model; use Core\Inventory\Model\Product as BaseProduct; class Book extends BaseProduct { // ... } // Query class namespace Bookshop\Inventory\Model; use Core\Inventory\Model\ProductQuery as BaseProductQuery; class BookQuery extends BaseProductQuery { // ... } 

It looks good, right? But:

 $book = BookQuery::create()->find($id); var_dump(get_class($book)); // expected: Bookshop\Inventory\Model\Book // actual: Core\Inventory\Model\Product 

AFAIK, this is because Propel relationships are defined at build time and not at run time ... The only way I found to achieve this is to use the extension behavior found in GlorpenPropelBundle and the definition of extended classes in my configuration:

 glorpen_propel: extended_models: Core\Inventory\Model\Product: Bookshop\Inventory\Model\Book 

Ok, this works, but of course, the best way? Am I missing something, or is this really the only way to extend models in Propel + Symfony? I really want to use Propel over Doctrine, but things like that leave me in mind that Propel is just not suitable for projects with a specific size ...

(Propel 1.6 + Symfony 2.3 btw)

Answer 1

The problem you are talking about is what you already wrote about the built-in runtime / runtime. Since BookQuery::create() is a static method, it resolves the BaseProduct class name of the BaseProduct model.

This is also described in the Propel manual:

Due to late static binding problems in PHP 5.2, you cannot use create() factory in an inherited query - unless you redefine it yourself in the descendant class. Alternatively, Propel offers a global factory query called PropelQuery :

 <?php // Use 'frontendBook' instead of 'Book' in the frontend to retrieve only // published articles $books = PropelQuery::from('frontendBook')->find(); 

Source: Propel Query Reference ^DOCS - Scroll down to the very end.

So either redefine it or specify it.

Hope this solves your problem as it allows you to specify which query and therefore the entity class will be used with propel.

The Glorpen Propel Bundle package uses a different route, changing the code that runs for the static getOMClass method. It smells like a blush in my nose, but it's too early for me to judge. You find the code in Behaviors/ExtendBehavior.php .

Answer 2

I am the creator of GlorpenPropelBundle, so I thought I could shed some light on the question :)

Propel provides model classes for modification, but unfortunately when it comes to the external bundle with their own model, in which classes are generated inside them. There are no second level user classes.

In some cases, you can use Propel's single inheritance behavior - http://propelorm.org/documentation/09-inheritance.html or the solution provided by hakre.

If you just want to add some methods to the provider model, you're out of luck. In the old days, there was http://trac.symfony-project.org/wiki/HowToExtendPropelPluginModel , but now there are some cases where this will not work - and this is where my package comes into effect.

If you are inside your own application, you can always extend the class as follows (since Propel user classes are generated only once):

 namespace Bookshop\Inventory\Model; //your custom class extending Propel base class class Book extends \Core\Inventory\Model\om\BaseProduct { ... } namespace Core\Inventory\Model; //propel user class extending your custom class class Book extends Bookshop\Inventory\Model\Book {...}