[Mulgara-dev] circular dependency between 'resolver-spi' and 'tuples'

Paul Gearon gearon at ieee.org
Mon Jan 18 20:07:02 UTC 2010


I had a discussion with Peter about this off-list, but I thought I'd
mention some of the more pertinent points here, for those who are
curious.

On Sat, Jan 16, 2010 at 8:04 PM, peter royal <peter.royal at pobox.com> wrote:
> On Jan 15, 2010, at 10:02 PM, peter royal wrote:
>> my take is to have query depend on driver. thoughts?
>
> I got past this by merging driver into query, as it was really thin.
>
> Now I hit another, 'resolver-spi' with 'tuples' and 'store-stringpool'.
>
> They are fairly inter-mingled, so I'm moving things out of resolver-spi into the other two as necessary to resolve things

There are two main approaches to dealing with these problems.

The first is to create new interfaces for classes. The interfaces get
put into some central location, and then the classes are only ever
referred to by those interfaces. In some extreme cases this even means
using reflection to create some of the classes. (yes, it's dirty).

The other approach is to bring everything we can into a central area.
Where it makes sense, then this is my preferred approach.

The reason for all the modules is to allow the resulting jars to be
brought together to create different deployment configurations.
However, some of the modules are more finely grained than they need to
be, which causes part of the problem.

To describe some of the systems:

Resolvers are meant to be completely independent, so they can be
written by a third party and then loaded up by the XML config file.
These refer to the resolver-spi, and whatever parts of the main system
they need access to. Nothing outside of a resolver should refer to a
resolver (except by the SPI), since it may not be loaded.

Content handlers are in an identical position to resolvers.

The rule engine was supposed to be loadable (and it *is*), but it
doesn't need to be. So it could be merged in.

Drivers are designed for remote API access to the system. These need
to be deployable on their own.

The Query section is the core of the system. Over time I'd like to
merge everything into this that is supposed to be part of a Mulgara
server. If it's not mandatory then it shouldn't be here, but if it is,
then it should be in here. You'll see a lot of unrelated packages in
this module, and it will grow over time as more stuff gets lumped in
there.

Query-lang covers the language modules. These exist sort of
independently of the Query module. They construct the algebra (or
operations) that the Query module is going to run. There's a nice
separation of tasks here, but I'm not sure if I see the need to have
them in separate modules. They could just keep their own packages to
enforce the separation.

All of the storage stuff is actually an implementation of a resolver,
which is why it's separate. However, it's in 8 separate modules when
it really only need be in one.

The Tuples module is for managing a data being returned from a query.
I don't know of anything that needs it that doesn't also need Query,
so this might be a candidate for merging.

The Util module is a set of utilities that anything might want, so it
does need to be on its own.

There's a few other bits and pieces, but that's the main part of it.

Regards,
Paul Gearon



More information about the Mulgara-dev mailing list