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. jesse On Jan 30, 2008 10:27 AM, Gordon Yorke <[EMAIL PROTECTED]> 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: > http://www.nabble.com/-Discussion--Continuum-2.0-Roadmap-tp15171171p15184536.html > Sent from the Continuum - Dev mailing list archive at Nabble.com. > > -- jesse mcconnell [EMAIL PROTECTED]
