Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


[RFC] model collections #266

havvg opened this Issue · 6 comments

6 participants


What do you think about model specific collections?

Those collections are pre-configured PropelObjectCollection for a given model.
They would follow the same principles as each model itself. A BaseUserCollection and a UserCollection would be created.
A respective ActiveQuery will always return an instance of this collection where applicable (not on count() etc.).

This would create a home for collection specific business logic.

An example use-case

A User may create a rated Review on a Product.
Now the ProductQuery would have a method getReviews which currently yields a PropelObjectCollection.

If you now want to calculate the average value of all attached reviews on the product, you would have to find a home for the new method. Let's say you created a Product::getAverageReviewRating which yields the average value of the rating of each review attached to the product.

This seems fine, but if you want to abstract such behavior, let's say the Product is related to a Manufacturer.
You could add a ReviewQuery::filterByManufacturer which yields another collection.

If both methods would yield a ReviewCollection and you would move the calculation of the average into ReviewCollection::getAverageRating, you can call this on any result set provided by any query done by the ReviewQuery.


-1 for me. We are already trying to reduce the number of generated classes by removing Peer classes, adding another one isn't such a good idea.

Besides, there is always the possibility to create a custom formatter to hydrate objects inside a custom collection class, so what you describe is already possible.

Lastly, for the use case you describe, I think a service class would be better suited than a custom collection class.

Alternatively, we could list, while building the query, a number of traits to be added to the ActiveRecord objects and / or to the Collection object. Something like addARTrait() or addCollectionTrait().


I have to agree, the generation of the classes is probably not the best solution for it. I didn't thought on another Formatter, that's actually a nice way to solve it - even for Propel1.

The traits listing sounds interesting, too!


Otherwise, you can create your own behavior and generate new classes for your needs.


Another benefit would be auto-completion for IDEs. E.g. eclipse had a bug on this, but that is fixed for the next version: Would be very handy for those of us.


Something along the lines was discussed yesterday on the mailing list!topic/propel-development/ZXvXHUSe7p4


I 'll be happy to be able to generate their own collections for each models. But I think that it should be implemented within the command model: build (example --use-own-collections option), instead a Behaviors or Traits. I use Propel because it provides a good code completion, and I absolutely do not mind a bunch of classes (if they do improve code completion).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.