docs and other directories..

[Martin van den Bemt <ml...@mvdb.net>]

Hi Tom,

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 ?
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 model.jude is a big question mark for me (though it could some UML 
specific stuff ?)
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 ?

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

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 ?

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)

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..

Mvgr,
Martin

Re: docs and other directories..

[Martin van den Bemt <ml...@mvdb.net>]

  specific, but if packages move or classes get renamed when there
>>are outstanding changes, it can be quite a pain.
> 
> 
> Well, yes, everybody has been through that - merging your own changes
> with those of others. But I think, DdlUtils is simple enough to make
> that rather painless.
> If I think a package should be renamed, I'll ask whether we should do so, ok ?

Announcing it will be enough :)

Mvgr,
Martin

Re: docs and other directories..

[Thomas Dudziak <to...@gmail.com>]

On 11/2/05, Martin van den Bemt <ml...@mvdb.net> wrote:

> > 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).
>
> The downside is that it is a pain to maintain the model xml in a java
> class, or you want to create the model directly from the model classes ?

For the model size that is IMO sufficient for the tests (about the
size of the models that are already used in the unit tests), I
actually think that they are easier to maintain in the code than i
separate files. I mean, a separate file would give you only a benefit
if you use a dedicated XML editor (which checks the XML syntax &
against the DTD) but you easily get this by running the test anyway.
And with inlining the short model, you don't have to worry about
loading external files which tend to be awark - either load from
classpath and ensure somehow that the test model files are in the
classpath, or load from file and force the execution of the tests in a
specific place. And with inlining you simple use a StringReader ..
The biggest benefit however IMO is that all is in one place. If
somebody wants to read the tests to gain info about how to use a
specific feature, or how DdlUtils maps something, then all info is in
one specific place, not spread out in multiple files.

> >>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.
>
> Nothing specific, but if packages move or classes get renamed when there
> are outstanding changes, it can be quite a pain.

Well, yes, everybody has been through that - merging your own changes
with those of others. But I think, DdlUtils is simple enough to make
that rather painless.
If I think a package should be renamed, I'll ask whether we should do so, ok ?

Tom

Re: docs and other directories..

[Martin van den Bemt <ml...@mvdb.net>]

See inline..

Thomas Dudziak wrote:
> On 11/2/05, Martin van den Bemt <ml...@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.

Brian sent me the mail, have not tested it though..

> 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.

I'll zap them :)

> 
> 
>>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).

We'll leave it in for now then, it's not in the way.

> 
> 
>>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).

The downside is that it is a pain to maintain the model xml in a java 
class, or you want to create the model directly from the model classes ?

> 
> 
>>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.

Nothing specific, but if packages move or classes get renamed when there 
are outstanding changes, it can be quite a pain.

> 
> 
>>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" ?
Ehh integration tests :) Got distracted with Ajax a bit (the soccer 
team, not "web 2.0"..
> 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.

Agreed...

Mvgr,
Martin

> 
> Tom
> 
> 

Re: docs and other directories..

[Thomas Dudziak <to...@gmail.com>]

On 11/2/05, Martin van den Bemt <ml...@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:

http://www.esm.jp/jude-web/index.html

> 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.

Tom