You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Matt Ryan <os...@mvryan.org> on 2017/05/05 16:40:53 UTC

Re: A federated data store

On Fri, Apr 21, 2017 at 7:20 AM, Davide Giannella <da...@apache.org> wrote:

> On 20/04/2017 19:30, Matt Ryan wrote:
> > I misremembered above when I was describing a possible implementation.  I
> > was thinking we'd add a method to the delegate, but that would be added
> to
> > the DataStore interface, obviously (not BlobStore or
> > GarbageCollectibleBlobStore).  Likewise, the default implementation would
> > exist in AbstractDataStore (not AbstractBlobStore).
>
> I like the idea overall and I'm not familiar with the DS codebase so
> what I'm saying can be wrong.
>
> If I think about the idea without knowing the current implementation I
> would expect some sort of API which allows for the Visitor pattern to be
> leveraged. In this way in an OSGi environment we could simply pull in
> all the Visitor services and act and in plain java it will be more
> around the repository construction/configuration.
>
>
Davide, thanks for the suggestion of using the Visitor pattern.

I spent a fair bit of time over the past couple of weeks researching the
Visitor pattern again and thinking about how it would apply.  I am not
opposed to using that or any other relevant design pattern (I'm generally a
fan).  But I'm struggling to see how the Visitor pattern would work here,
so maybe you can help me see what you had in mind.

From [0] there is an image of a sequence diagram for the visitor pattern
[1] that is essentially taken right out of the GoF "Design Patterns" book.
Looking at the sequence diagram and trying to map it to this problem:
-  I believe the class labeled "xx:Composite" would be the
FederatedDataStore (some class within this component).
-  I believe the classes labeled "anA:ConcreteA" and "aB:ConcreteB" would
be delegate data stores, e.g. FileDataStore, S3DataStore, or something like
that.
-  I believe the class labeled "v:ConcreteVisitorType1" is ... ???

That's where I get stuck - I can't figure out what the delegated data
stores would be visiting.

In the GoF "Design Patterns" book for the Visitor Pattern under
"Applicability" (page 333):
-  Bullet one says use the Visitor when "an object structure contains many
classes of objects with differing interfaces".  Shouldn't be the case here
- all the data store delegates should be able to be treated pretty much the
same.
-  Bullet two says use the Visitor when "many distinct and unrelated
operations need to be performed on an object structure, and you want to
avoid 'polluting' their classes with these operations."  I don't think this
applies either - the operations are slightly different implementation but
similar in purpose, and are not unrelated; we don't need to perform many
operations but rather select which one is right; we actually do want to
'pollute' their classes with the operations, because it is within those
classes where the logic to do the operation is contained.

Can you help me see what you had in mind?  I think I'm missing it.


[0] - http://www.ghytred.com/ShowArticle.aspx?VisitorPattern
[1] - http://www.ghytred.com/images/visitor2.jpg


-MR