You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Jesse McConnell (JIRA)" <ji...@codehaus.org> on 2007/03/09 20:28:15 UTC

[jira] Updated: (CONTINUUM-476) jdo model improvements

     [ http://jira.codehaus.org/browse/CONTINUUM-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesse McConnell updated CONTINUUM-476:
--------------------------------------

    Fix Version/s:     (was: 1.1-alpha-1)
                   Future

> 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: Future
>
>
> 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