There is one particular reference to a thread at the bottom of the
wiki page linked below, but the main reference thread would be the
target architecture one [1] (I'm not sure why Markmail has stopped
detecting threads though...).
It is not so much to remove, but decouple so that it will run with
basic functionality without the database.
That theme is probably scattered, so I can summarise:
- derby takes quite a lot of memory which is a potential hinderance to
running your own instance
- the performance of populating the database has been poor on a large
repository
- harder to diagnose problems when the database is not in a consistent
state
- we don't particularly take advantage of the "robustness, reliability
and scalability" of the database as it effectively acts as a cache for
the local storage, doesn't handle concurrent servers, etc.
More importantly, there are a number of things about the current
design (not necessarily the database) that are a barrier to
contribution IMO. Some parts are quite tightly coupled, and the
database code is mixed in to the model. There is a mix of using paths
and artifact references which causes a lot of back and forward
conversions, and some Maven concepts are baked in that don't make
sense for other repository types. The over-reliance on scanning which
is a hang over from the very first code I checked in is biting us
worst of all I think.
I hope this all makes sense :)
Cheers,
Brett
[1] http://markmail.org/message/6o6byzjsccgzgkmr
On 01/12/2008, at 2:24 PM, Martin Cooper wrote:
Hey Brett,
Do you have a handy link to the previous discussions you mention? I'm
curious as to why someone would elect to give up the robustness,
reliability
and scalability of a database, since I would have counted those as
assets
rather than something to work to remove.
Thanks!
--
Martin Cooper
On Sun, Nov 30, 2008 at 7:13 PM, Brett Porter <[EMAIL PROTECTED]>
wrote:
Hi,
Just a short note - in line with the previous discussion we've had
about
decoupling the database such that Archiva will run without it (but
can use
it for additional stats, etc through a plugin), and setting up an
extensible
metadata format, I've continued the work under MRM-1025.
See: http://svn.apache.org/viewvc/archiva/branches/MRM-1025/
and: http://cwiki.apache.org/confluence/display/ARCHIVA/Metadata+storage
Any comments, questions, volunteers? :)
- Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
