See inline..
Thomas Dudziak wrote:
On 11/2/05, Martin van den Bemt <[EMAIL PROTECTED]> 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
