[ http://jira.codehaus.org/browse/CONTINUUM-476?page=comments#action_80138 ] Jesse McConnell commented on CONTINUUM-476: -------------------------------------------
I would really like to set the store api cleared up in general with this. Its frustrating to try and balance all of the 'do I have build definitions in the project instance I just asked for?' joakim and I ended up working out some really nice conventions for accessing objects and dealing with things in the plexus-security store in terms of save* and get* operations. I think we could really go a long ways towards making continuum more maintainable if we were able to just bite the bullet and refactor the store api and the underlying jdo store. programming against the current api just feels really hit or miss. > jdo model improvements > ---------------------- > > Key: CONTINUUM-476 > URL: http://jira.codehaus.org/browse/CONTINUUM-476 > Project: Continuum > Issue Type: Improvement > Components: Core system, Database > Reporter: Brett Porter > Fix For: 1.1 > > > some notes I sent to the dev list earlier in the year > There are afew areas I'm still not happy with. The fetch groups don't > seem to fit well with what is required a lot of the time. I'm wondering > whether we are better off making everything be in the default fetch > group, and lazy loading the lists instead. It seems since we are only > doing this as an optimization that'd be a better way to do it. > We'd still need to avoid long lists, ie build results. I think that > should not be a field on the project, and instead it should just have > references to the last successful build, last finished build, current > build (either in progress or finished). > I'm not particularly happy with using store methods "mid-way" through a > block of code. I'm not sure if it does any dirty checking when you do a > re-attach,but I see potential to read something, have it changed > externally, then write over the top of it. The fact that we are > re-retrieving from the db at random points could make this harder to > track. I think we should be in the practise of getting all we need from > the db at the start, modifying the detached objects, then updating them > with dirty check at the end. We need to be able to resolve common cases > where we can recover, and fail gracefully when it can't. At the end of > the day, this isn't preventing it working now, so I'll just schedule a > review of the use of the store later as it may be a source of ongoing > bugs otherwise. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
