Hi Jacek,
This is probably not a completely fair comment but it is well taken. We
know that the XML parsing is a big mess
(https://forge.continuent.org/jira/browse/SEQUOIA-4) that should be
fully redesigned using more modern technologies (i.e. not SAX). When you
don't have resources, you tend to focus on added functionality than
redesign for just the beauty of the design with equivalent
functionality. Also this project has to carry 6 years of history
(including legacy technologies) which is not as easy as redesigning from
scratch with current technologies.
Sequoia's design is quite inflexible to plug new load balancing policies
with granularities that are not at the table level. Now I don't
necessarily agree that you need interfaces everywhere to follow the "OO
rules". Some classes like Controller are final because they were not
designed to be overridden (it's on purpose!).
Proposals to extract new interfaces are welcome. Note that we mostly use
abstract classes rather than interfaces for core components since they
allow better code factorization. The public APIs are basically the JMX
interfaces.
Regarding factories, they are mostly used to externalize database
dependent behavior. For core components, some of them have very close
interactions with each other and must be instantiated and initialized in
specific orders . Factories won't help much there.
If you can provide more specific evidence of interfaces or factories
that you would need to introduce, don't hesitate to write up a proposal
and why not open a JIRA issue to track the discussion and attach
eventual patches or documents.
Thanks for your valuable feedback,
Emmanuel
I have started to look at the source code of Sequoia. After short
review I have found that it will be hard to add a new functionality
without changing existing source code or writing my own
implementations of some methods using "copy and paste paradigm". No
offence, but in my opinion Sequoia is not well designed, it is not
module/plugin oriented, uses too few interfaces and class sources have
enormous sizes. For example it is really bad thing to override a
method which has about 300 lines of code - see
DatabasesParser.endElement (I want to change only a couple of lines of
these 300 lines of code so I must copy and paste almost whole method).
The project also does not follow the OO rules. It is very tightly
coupled - there are only few interfaces. There is also a lack of IoC
configuration (ie. Spring) or some central place (e.g. factory class)
where all the instances are created (just by reimplementing this class
I would be able to change implementations of every functionality).
Finally Controller class is final so I cannot override it.
I want to be able to upgrade Sequoia in the future, but I would also
like to use my own features which I have made before. But because of
the facts that I have introduced, it is really hard to upgrade without
any problems.
Personally I think that Sequoia is really good stuff, but it need to
be redesigned a little.
Best regards
Jacek
On Wed, Mar 5, 2008 at 8:29 PM, Jacek Olszak <[EMAIL PROTECTED]> wrote:
Hi Emmanuel,
thanks for reply. So, I will try to implement my own load balancer
which will be responsible for Shard selection. After that it will
forward the request to RAIDb-1 load balancer which will choose a
backend.
I will write here about my progress.
Regards
Jacek
On Wed, Mar 5, 2008 at 11:34 AM, Emmanuel Cecchet
<[EMAIL PROTECTED]> wrote:
> Hi Jacek,
>
> From what I understood, Shard is supposed to do the request
> dispatching. Now if you want the availability part to be handled by
> Sequoia, you can use a RAIDb-1 Sequoia cluster (full replication) for
> each Shard partition (and Sequoia will just do the load balancing among
> replicas of the same partition).
> If you really want to do the row-based partitioning in Sequoia then you
> will have to implement your own load balancer or integrate parts of the
> Shard logic into a Sequoia load balancer.
>
> Hope this helps,
> Emmanuel
>
>
> > I want to create some basic application which will use shards. I mean
> > the application which will use many real databases partitioned in some
> > way (by range, hash etc.). So I have one table which reside in
> > multiple databases, but in one database I have only a part of rows. I
> > want to use Sequoia as a request dispatcher. It will be responsible
> > for select what database will be used to a given query. I read the
> > documentation and didnt find similar solution. There is only RAIDb-0
> > which split database by tables. But I want to split rows in tables
> > instead. How can I implement this using Sequoia? Should I implement my
> > own load balancer?
> >
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
