Little refactor: Created a trait with a common pattern in VOMongo*Operation hierarchy.

[tinchodias]

All operations need an instance of MongoDatabase so I created a trait with an accessing method that operations use.

I want to try the MongoSDAMClient, which provides the MongoDatabase instance in another way, and it's much simpler to have a single point where to change it.

[tinchodias]

I think there is no problem to use a trait in voyage, isn't it? I mean something about compatibility.

[noha]

I don't understand the change. It is a one method trait that you have to add to the base class. So I cannot see that anything changed but complexity added. Can you explain the rationale? As we support only version of pharo >= 5 using of a trait should be no problem

[tinchodias]

Thanks for the feedback. I pushed an extended version of this PR that should make it more meaningful. The rational is that not all voyage back-ends have pool nor specialized reading and writing pools as the mongodb one. But that may be wrong... if you tell me that all backends should have these pools, then my PR is wrong.

[tinchodias]

Any further opinion? still looks like bad idea?

[noha]

I never said it is a bad idea. I just don't understand why this is a good one. I agree that assuming a pool always might not look right. So the change to have calls with just read database and write database are good. This is a left over from the refactoring and the repository should decide about having a pool or not. But it was only in the mongo operations where it is the case. What I don't get is to make a trait for what reason if you add it to all the classes. That is why I said on first view it just adds complexity. But I can live with that if it is important for you ;)

[tinchodias]

Now there are no traits.

[noha]

And do you miss something? 😉

[noha]

Thanks for changing it. I don‘t want to be the blocker

[tinchodias]

;)