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

[Thomas M. <tho...@ho...>]

Hi Joachim,

Joa...@tp... wrote:

> Hy,
> 
> I've got several questions. First of all I still got the trouble with MySQL
> failing a Broker Test (PersistenceBrokerTest.testEscaping()) and it doesn't
> seem that this will be resolved, unless we change the Test. MySQL doesn't
> have a problem with the escaping but with trailing spaces (the get striped
> in the database). I suggest that the trailing spaces in the escaping Test
> are removed.


I agree. This test must only check proper treating of quotes.

> The questions is whether we want to do the
> trailing-spaces-Test as well (which would again result in a Failure with
> MySQL, but at least it would be more precise). I'd be willing to make this
> Change, if no-one objects.


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 there is my newly created Option for SequenceManagerHighLowImpl, which
> allows for OID that are unique over all classes (to be exact they are
> unique over all classes that use the same name for their ID-field. This was
> necessary to allow the JUnit tests to pass and will not be a problem,
> 'cause when you use this function you're likely to use an oid-field (or
> something) for all classes). The implementation cannot really handle Data
> being inserted into the DB without using it for acquiring the IDs with this
> function. So it is quite useless for accessing legacy data, but for our
> product it is just fine (we won't have any DB-access without OJB). 


This is a cool functionality! feel free to contribute it.

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


> 
> Well, basically most of my questions boil down to one point: are there any
> cvs-checkin rules that should be obeyed? Not breaking the JUnit tests seems
> to be an obvious test.


Yes, this is an essential point !

> Any others? How about new functionality, should it
> be discussed on this list before check in? Bug fixes?
> 


We have not yet any fixed set of rules yet. I'm planning to provide a 
little document on this topic. For the time being here are some guidelines:

1. Before checking in code, please assure that all things compile and 
that all JUnit tests pass successfully.

2. Before checking in code please check for conflicts with checkins of 
others. IDEs like eclipse will help you to merge things together.
Before commiting merged files please again check 1.)

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.

  4. Before starting major refactorings or adding new features please 
make a proposal to the developer list for discussion. If there are no 
objections: feel free to start.

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


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


should be no problem!

cu,

Thomas


> 
> regards
> Joachim Sauer
> 
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
>