Collection decorator doesn't delegate methods such as where and other query methods.

[fuadsaud]

As I understand the decorator pattern, it should not hide features from the underlying object. This makes the decorated collection incompatible with the interface of the original collection. Can this feature be added? What do you think?

[naps62]

If you don't want to hide features of the underlying object, you should use delegate_all as explained in the Readme

[fuadsaud]

We're talking about collection decorators here. delegate_all seems to only be available through normal decorators.

[donaldpiret]

+1 on this

[donaldpiret]

This seemed to have been implemented in #257, but lost somewhere along the way

[fuadsaud]

Yes. I also wonder why. It drives me crazy to the point I'm stopping using collection decorators :(

[donaldpiret]

I have a pretty good idea of how to fix this properly, but currently lacking time to make a proper pull request for this. Will try to do so this weekend or early next week.

[tovodeverett]

I suspect the pull request will be rejected, and there are some good reasons for this. For performance reasons, CollectionDecorator caches the decorated instances and provides an interface. As a result, delegate_all is not supported for CollectionDecorator because it would permit a whole host of issues to arise if users issue methods that modify the underlying collection, because those modifications would not be mirrored in the existing decorated collection.

See #388 for my experience in this rabbit hole.
See #425 for a more recent raising of this issue and the response.

[donaldpiret]

Thanks for the input, and for the referenced stories. I think I'm still going to try my luck, mostly because I need this functionality for one of our projects (we've managed to hack our way around for now, but I'd really rather clean things up).
I don't actually intend to touch the collectiondecorator, but am exploring the idea of a proxy object to provide better support for relations that sits on top of it (which is what the very first implementation seemed to be doing as well). Regardless of wether it gets merged or not, at least I hope the associated fork might prove to be useful for people who find themselves with the same needs as we do.

[donaldpiret]

So I gave it a shot: #610
Would love to get some input on this, even if it's just to shoot it down :)