db-ddlutils-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <tom...@gmail.com>
Subject Re: docs and other directories..
Date Wed, 02 Nov 2005 21:20:47 GMT
On 11/2/05, Martin van den Bemt <mllist@mvdb.net> wrote:

Hi Martin,

don't know whether Brian send you a notice, but you should now have
write access to DdlUtils, he sent a mail earlier today to the DB PMC.

> Just went through the src directory and I have some questions regarding
> the usage, etc..
> First src/doc
> I assume this is forrest stuff, of which I lack major experience. Do I
> need a specific version of forrest to build the docs ?

Yep, that's Forrest. You need version 0.7 to build the docs. Simply
unpack it somewhere, set the environment variable FORREST_HOME to the
root directory and you should be able to build the docs.

> Looking through there I just target stuff at the
> doc/src/documentation/content/xdoc directory and just leave the rest
> alone for now (untill I get more familiar with it).

The rest was auto-generated by Forrest. Interesting to us are only the
forrest.properties and the files under content/xdoc.

> The model.jude is a big question mark for me (though it could some UML
> specific stuff ?)

Yes, Jude is an UML tool:


> I assume the /xdocs directory (the old maven docs) can be deleted or do
> you still want to move some docs from there to forrest ?

You're right, there are a few files that I did not touch yet.
The old docs can surely be removed, they don't have anything to do
with DdlUtils anymore anyway.

> The src/xml dir contains the database2ojb.xsl, is this still usable?

I never used it but since I didn't touch the DTD, it might very well
be. But then again, would use would it have ? I think we better drop
it, or else move it over to OJB (might be useful there, at least once
it also creates Java classes, perhaps with Antlr's StringTemplate).

> The src/test-input
> Is this already "the" database model for tests or should we consider
> making another model (eg using the petstore model, since everyone is
> making a petstore application as example for their web frameworks), or
> just let "the" model grow/improve when the need is there ?

Actually I don't think a single model for the test is useful. Rather,
we should have different models for testing certain aspects. Eg. a
dedicated model to test foreignkeys (including perhaps circular
relationships), a dedicated model to test blobs etc.
Also I'm more into putting the model into the test case, makes it IMO
easier to keep them in sync and to read the test (all stuff necessary
to understand the test in one place).

> And another one : do you still have some more package renamings coming
> and if you do, which packages (so I can leave these packages alone for
> the time being)

What large scale stuff do you plan to do ? ;-)
I think the package structure should be good now and the platform
concept works IMO very nicely.

> Still thinking about how to seperate the integration, in the simplest
> way to test eg roundtripping, since eg you want to test hsqldb 1.7.x and
> 1.8, to see if roundtrip works ok for the latest version and the
> mainstream version. If you have any thoughts already about that, let me
> know..

What do you mean with "seperate the integration" ?
For testing the roundtripping I think it is necessary to create a
couple of tests testing a specific aspect: a model with single tables
with (together) all JDBC datatypes, a model with indices, a model with
autoincrement column(s) (not every database supports multiple such
columns), a model with foreignkeys, a model with default values for
columns etc.


View raw message