On 6 January 2013 23:17, Matt Franklin <[email protected]> wrote:
> On Sunday, January 6, 2013, Jasha Joachimsthal wrote: > > > On 6 January 2013 21:44, Matt Franklin <[email protected] > <javascript:;>> > > wrote: > > > > > On Thu, Jan 3, 2013 at 2:27 PM, Chris Geer <[email protected] > <javascript:;>> > > wrote: > > > > On Thu, Jan 3, 2013 at 11:49 AM, Matt Franklin < > > [email protected] <javascript:;> > > > >wrote: > > > > > > > >> On Fri, Dec 28, 2012 at 10:54 AM, Matt Franklin > > > >> <[email protected] <javascript:;>> wrote: > > > >> > The MongoDb branch is about ready to be re-integrated into trunk. > I > > > >> > am currently going through and fixing merge conflicts caused by > the > > > >> > model-interface split. Currently, the only changes to the current > > > >> > working code are some application context improvements and > > additional > > > >> > configuration attributes. In order to ensure that the jpa & mongo > > > >> > modules were swappable, I tried to isolate the changes as much as > > > >> > possible. Because of this, I think the risk to trunk is pretty > low. > > > >> > > > > >> > Assuming no objections, I will merge it back to trunk before the > end > > > of > > > >> Monday. > > > >> > > > >> Of course, I forgot Monday was New Year's eve. I have completed all > > > >> of the work now and committed the branch back to trunk. > > > >> > > > >> The vast majority of changes are isolated into the rave-mongodb > > > >> project. I did add new build profiles for rave-portal and > rave-portal > > > >> resources so that the entire rave-project can be built with MongoDB > as > > > >> the default persistence provider. However, the default profile is > JPA > > > >> and the rave-portal & rave-portal-resources releases will still be > set > > > >> for JPA persistence. > > > >> > > > >> I tested a clean build of the JPA version of rave and saw no issues > > > >> with the merged code. > > > >> > > > > > > > > Matt, quick question for you. I noticed that the group table > > (collection) > > > > doesn't just contain a list of user IDs but instead contains complete > > > user > > > > objects. What happens if the user object stored in the group and the > > user > > > > object stored in the users table get out of sync? Can that be > > simplified > > > to > > > > just store the IDs? > > > > > > Yes, it should be. I will create a JIRA ticket. > > > > > > > > > > > Have you done any tests using multiple providers for different > > entities? > > > > For example using Mongo for Users but JPA for Pages? The model split > > > should > > > > allow that but I don't know if the providers will allow for that. > > > > > > No, but doing this and documenting is important. > > > > > > > We also should find a more elegant solution than building multiple > modules > > with the mongodb profile to use MongoDb, but I haven't found a clean > > solution yet. > > > +1. I think we need to work a lot harder on making sure we have clean > abstractions > > We can probably use a classifier [1] to distinguish the mongodb version of the artifacts [1] http://maven.apache.org/pom.html#Dependencies > > > > > > > > > > > > Can't wait to try this out! > > > > > > > > Chris > > > > > >
