continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Continuum: where to now
Date Thu, 18 Aug 2005 02:05:13 GMT

Ok, here's a summary of what I did with the continuum model:
- rebuilt the model from scratch based on the web design.
- implemented it separately and tested it thoroughly in isolation.
- migrated the app over to the new model, removing the old one

Changes in the new model:
- package is o.a.m.c.model.* (added model. to the package), removed
Continuum from the class names. This is consistent with m2's use of the
- many-to-many relationship was broken down into 1-to-many. This was
necessitated by the design, not any technological limitation.
- added dependant relationships for most
- changed identifiers to integers rather than string ints, and removed
id fields from those not meant to be looked up on their own
- constructed fetch groups based on the page flows
- other small things, eg "forced" changed to "trigger" so we can track
what caused the build (web, soap req, schedule, etc)

Things still broken:
- I haven't gone back and updated velocity templates. Doing that now.
- There may be some more bugs in the web stuff that wasn't covered by
the integration tests. I'm checking it over.
- I haven't done the persistence/testing for the users/permissions stuff yet

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.

So, where do we go from here?

I would like to see us knock off all the pages in the design as soon as
possible. This should be the easy bit as it is all just forms and
presentation now I believe. Some of the features aren't supported in the
backend yet (like security, displaying test reports, generated
artifacts), so they can be omitted for now. Does everyone agree?


View raw message