Thanks Cees, I had a look at the tests, then I'm happy because now 
because
I know a bit more the problems that encounter real professionals when 
mapping dead data to real objects, especially when a table is a nary 
relationship between different table (object). In my case I just had to 
extract three stupid tables and one of those nary table so I hacked it 
by hand with select and creating temporary objects. But now I 
understand the value that something like Glorp (if non buggy) can have.

It was pleasant to learn new stuff (my lecture on DB long time ago was 
only on simple and naive sql queries).

Thanks for the advice

On Saturday, August 2, 2003, at 11:54 AM, Cees de Groot wrote:

> On Thu, 2003-07-31 at 16:12, Stephane Ducasse wrote:
>> I know that some of you are suing glorp. I would like to know if there
>> is a small documentation or tutorial.
>>
>> I went to sourceforge but the doc link was broken.
>>
> Your best bet is to peruse the higher-level unit tests. They have at
> least all the possible mappings, and most of the interaction. It does
> help tremendously if you're up-to-date generally with the basics of O/R
> mapping.
>
> One thing to keep in mind is that that Glorp has two things that may
> take you by surprise and still a bit of bugs. The two things are:
> - An object cache that still doesn't work 100%. It is good to at least
> reset it (GlorpSession>>initializeCache or something) before each 
> query.
> - Queried, traversed objects and their (mapped) transitive closure are
> all automatically registered. Which means that usually you only need to
> GlorpSession>>register: newly created objects, Glorp will persist the
> rest for you as needed.
>
>
>
>
>
>