continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse McConnell" <>
Subject Re: [Discussion] Continuum 2.0 Roadmap
Date Wed, 30 Jan 2008 19:34:51 GMT
How important is the database really to things in continuum?

To me it has always seemed somewhat of an annoyance to have to manage and
maintain when so much of things could just be some xml files on disk.  There
isn't a great amount of search functionality in continuum that in my mind
begs a solution where someone could increase performance by tuning some sql
statements.  The largest chunks of historical data we maintain are things
like build results and they could discovered and indexed in memory pretty
easily I could think...

but if we are going to stick with the database then I think the api needs to
definitely take into account a more distributed nature where multiple
continuum instance would feed into a single database...make it so that we
can generate interesting information across mutliple distributed continuum
instances out of that central database.  I would also like to suggest that
we either make use of a jdo impl that provides for lazy loaded objects where
interacting with something like Project and calling a method on it will
automatically populate what you need in your code, or else we implement it
in a wrapper on these object so that the API into the store can be cleaner
then this getProjectsWithEverythingUnderTheSunPopulated() vs
getProjectThatYouAreEnsuredToNotHaveDataYouWantPopulated() methods.

my 2 cents...maybe jpa would help clean this up but I know rahul and emm
were talking about that not too long ago query wise...I think it would be
most excellent to have one method to getProject() out of the store and have
it be useful everywhere and all of the fleshing out of its content managed
behind the scenes.


On Jan 30, 2008 10:27 AM, Gordon Yorke <> wrote:

> TopLink has a large community of users and active forums at both Oracle
> and
> Glassfish.  If you are concerned about licensing, Oracle has donated the
> full TopLink source to the Eclipse Foundation under the Eclipse
> Persistence
> Services (EclipseLink) project.  If you have any questions the EclipseLink
> dev mailing list is well monitored.
> --Gordon Yorke
> Rahul Thakur wrote:
> >
> >
> > 2) Database
> > I am not hard and fast on any particular JPA provider. If Toplink cuts
> > it, we should go with it. I have been toying around with OpenJPA, but I
> > haven't used Toplink to comment on how both compare. OpenJPA is
> > comprehensively documented and has a good support available on mailing
> > lists. Having said that, JPA providers would ultimately be swap'able
> > under the hood.
> >
> > Also, I think we should stick with JPA annotations on model entities
> > instead of using Modello. I hope writing the data access code from
> > scratch implies the current ContinuumStore will be refactored into
> > something which is less verbose than what we have currently, and so
> > would the Continuum interface.
> >
> >
> --
> View this message in context:
> Sent from the Continuum - Dev mailing list archive at

jesse mcconnell

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message