[RFC] model collections

[havvg]

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.

[fzaninotto]

-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().

[havvg]

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!

[willdurand]

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

[gossi]

Another benefit would be auto-completion for IDEs. E.g. eclipse had a bug on this, but that is fixed for the next version: https://bugs.eclipse.org/bugs/show_bug.cgi?id=201108 Would be very handy for those of us.

[mhitza]

Something along the lines was discussed yesterday on the mailing list https://groups.google.com/forum/?fromgroups=#!topic/propel-development/ZXvXHUSe7p4

[sorbing]

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).

[SCIF]

Current state of model collections is some odd: you allowed to hydrate collections by checking of class existence, but generated phpdoc still old and don't contain name collections, which is very useless in IDE. Also, php7 will bring ability to use strict returned type definition, which will rise relevance of current feature (we can check config «use php7 features» flag in config and generate according code).

I suggest add boolean key «generator.named_collections» to configuration or attribute to database in schema. We can add this feature as disabled by default if you afraid to generate large amount of files, but user will have ability to decide which strategy to use. Cli key for command is some little bit worse for me, but much better than nothing :).

Also, current implementation force to store collections in same folder as models. If we will add support, we can add ability to select naming strategy which follow on collection creation (i prefer using namespace Collections node).

[dereuromark]

We will have to open a new discussion here for 2022+