Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[stellation-res] Databases, artifacts and all the rest... 
Hello,

It took me some time to catch up on all the mails. Although I'm not
very experienced with database back-ends, I do have some ideas on the
cooperation between the artifact agents and the database access layer.

Before I go into the artifact area, I would like to go back to the
requirements of the database layer: to abstract away the differences
between the RDBM systems that can be used together with Stellation. As
a result, it's wrong to go into the direction of a one-size-fits-all
solution. In this context, the template mechanism is a good example of
doing something the *wrong* way. On the other hand, using an XML
description of the database structure is not flexible. First reason to
avoid XML: the XML description should be kept in sync with the code:
error prone! Second reason: we will end up with an XML for the core
Stellation and an XML document for each of the artifact types. One
question I ask myself is if the XML descriptor can be written database
independent. 
I think that we should be able to derive our database layout from our
code model. It's already hard enough to keep one model clean... :)

About artifacts:
<statement>
We don't go far enough in using artifact types!
</statement>
I wondered why things like versions, projects, branches are not
modelled as artifact types. There are tables for it, why not model it
as artifacts then? I could start modelling artifacts like a solution
map (is it clear that I'm a VisualAge for Java user? :), bug reports
(why split bug tracking from development?), ...
Having nothing but artifacts would remove the need for
DBAccessPoint.createRepository. At this point in time, we already have
the SQL in one place: the ArtifactAgents and no longer in
DBAccessPoint.

About database abstractions:
<statement>
The database abstraction layer should be the only place that constructs
SQL statements.
</statement>
Having nothing but artifact types, I came up with having the SQL in the
ArtifactAgents, so away from the DBAccessPoint. It's true that it seems
to conflict the statement I make in this section, and true you are! I
haven't had time enough to come up with a clear answer or direction,
but the only thing I can say is that artifact agents should be able to
speak to the database access layer in a standardised API on how to
store and retrieve the information belonging to the artifact type. The
specific implementation of the database layer can then generate SQL
statements optimized for the RDBMS in use. Maybe OJB(1) can provide us
with a lot of support in this area. On the other hand, my view on this
matter could be oversimplified, but then I would like to hear from you
all.

(1) http://jakarta.apache.org/ojb/

Ringo

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Back to the top