Re: [OJB-developers] JUnit Tests & MySQL / global IDs

[<Joa...@tp...>]

hy all,

[snip MySQL and testEscaping with trailing spaces]
>
> I agree. This test must only check proper treating of quotes.
>
[snip]
>
> Mh, I don't think that we really need this TestCase. It's also of
> little use as we know that it is doomed to fail with MySql.

Then I'll change the test to leave out the trailing spaces.

[snip global ids]
> This is a cool functionality! feel free to contribute it.

I will commit it as soon as I've got a more flexible Configuration System
working.

>> The function is not yet configurable (except for setting
>> globalSequence = true in the constructor and recompiling), as I
>> don't to wait for the rewrite of BaseConfiguration (which I would
>> volunteer to do, if no-one has started work on it yet, maybe if
>> anyone has any design ideas. If not, I'll just do it how I see fit
>> ;-)
>
>
> I think that no one has started on the refactoring of the
> Configuration stuff. So you can just give it a try.

OK, I'll try this. My idea is to unite Type-Conversion and Default-Values
so that an incorrect entry could result in a good log-entry and the default
value beeing used. something like getBoolean("someConfiguration", true) and
getInteger("someConfiguration", 42) and so on.

[snip cvs checking rules]
>
> 3. If you are checking in code that implements new features, please
> also provide JUnit Testcases that validate the new functionality. If
> the new features are visible to the end-user please also add (or
> modify) documentation.

do we also need JUnit Tests for such configureable features as the global
High/Low ID Generator? The Problem here is the same as with JUnit tests for
the C/S-mode. We'd need to  modify OJB.properties to test these features.
We either make a general system for changeing specific configuration
entries for specific tests or rewrite the build.xml to re-run the tests
with several alternate configurations. Does Sourceforge allow running
automated regression tests on their system? This way we'd be able to run
regression tests against several databases every day. If sourceforge
doesn't allow such things, we could do this on our internal system (we have
similar regression tests, along with auto-generated documentation for our
internal project) as soon as our server is back to live (right now he is in
a rather bad condition).

[snip]
> 5. We currently don't have a proper change management system. But
> there is a excel file (todo.xls) in the base dir of the OJB-1-0
> project. Please add your changes to this file. This file is used to
> assemble the change log for new releases. Thus it is important to
> register all changes here ! (If you have an idea how to provide a
> better change management please contact me.)

I suggest we don't use and excel file, for several reasons, some of which
are just my personal taste and might therefore not be inportant:

- many people don't run Windows & those who do might not have Excel
(fortunately I (have to) use Windows and work and do have Excel installed).
- cvs can't give you a meaningfull diff of any Office document.
- security implications (cut & paste from/to office documents might copy
more than is visible)
- i don't like Excel ;-)

a simple text-format TODO might be an alternative. Granted, handling this
would be a bit more complicated, but at least everyone can do it. Another
idea for a changelog might be something along the lines of cvs2pl (to be
found at http://www.red-bean.com/cvs2cl/), I just recently found it and
haven't tried it, but it looks interesting.

(I'll just update my changes there nevertheless, until we find an
alternative)

>> btw, anyone got a problem, when I check in a .cvsignore file into
>> CVS that contains *.class?
>
> should be no problem!

I should read the cvs-documentation before doing such things ;-) .cvsignore
only works in the current directory, so I now use "build" and "dist"
instead of "*.class".

> cu,
>
> Thomas

regards
Joachim Sauer