-------- Original Message --------
Subject: Re: DescriptorRepository and ReverseDb
Date: Sat, 15 Jun 2002 23:14:05 +0200
From: Thomas Mahler <tho...@ho...>
To: Florian Bruckner <bf...@fl...>
CC: obj...@li...
References: <LLB...@fl...>
Hi Florian,
Florian Bruckner wrote:
> Hi!
>
> Having found some spare time again I'm looking into integrating
> DescriptorRepository and friends into ReverseDb. Unfortunately I'm having
> some problems with the design.
>
> My first problem is that DescriptorRepository requires the classes
already
> to be there in bytecode. While this is perfectly ok with the normal
use of
> DescriptorRepository this is a major problem for ReverseDb, simply
because
> at that stage you usually do not have the classes.
Right. I anticipated your problems already when I had a short look at
your reversedb code some time ago.
> To be able to use
> DescriptorRepository with ReverseDb there must be a possibility to load a
> repository and create ClassDescriptor objects without the necessary
classes.
I agree. We really need this feature!
> I have not looked at the implementation of these classes yet, but I frear
> that this might require a major redesign of these classes.
Some work is needed, but I don't think it's going to be a major redesign.
It's not really required to load the persistent classes etc.
immediately. I think it can be delayed until clients try to access them.
> On the other hand
> it would be nice if we could use the DescriptorRepository framework in
> ReverseDb (at least in a useful way).
>
I agree. I want to have *all* mapping metadata in the
DescriptorRepository and nowhere else.
> The second problem is the singleton design of DescriptorRepository.
We have to get rid of this too!
> While it
> is possible to create new instances of the class, some other classes
in that
> framework rely on the fact that it is a singleton (e.g. ClassDescriptor
> accesses DescriptorRepository by its getInstace() method). In a GUI
> application (at least in a GUI application I'd like to use) you should be
> able to open multiple windows with OJB repositories, maybe because
you want
> to compare the content or maybe you want to copy class descriptors or
other
> elements from one repository to the other.
>
I agree. There are other places (e.g. PersistenceBrokerFactory) that are
already prepared to work with multiple repository instances.
> While the second problem could be worked around by simply allowing
only one
> instance of a repository-editor-window to be opened, the first issue
would
> make it necessary to create a "functional copy" of DescriptorRepository,
> which I'd like to avoid if possible.
>
> Any ideas or comments how we could proceed here or do you think these
> requirements are so out of scope for OJB that it is not feasable to
> implement them?
>
We should work on the necessary refactorings as mentioned above! We want
to have several metadata tools that can't live with the current
restrictions!
> best regards,
> Florian
>
> PS: I'd like to check-in a completely redesigned prototype of
reversedb when
> the repository has been migrated to jakarta if nobody objects. I
think the
> design is more flexible now and could serve as the basis for a complete
> reverse-engineering, repository-editing tool.
>
no objections. Just go ahead!
cheers,
Thomas
|
