Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Message-ID: <40F27EED.3090101@first.fhg.de>
Date: Mon, 12 Jul 2004 14:07:09 +0200
From: Thomas Dudziak <tomdz@first.fhg.de>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
MIME-Version: 1.0
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: ojb 1.1 ideas and proposals
References: <40F02E7C.3040105@first.fhg.de>
 <F57CDCE4-D3F4-11D8-B95F-000A95782782@forthillcompany.com>
In-Reply-To: <F57CDCE4-D3F4-11D8-B95F-000A95782782@forthillcompany.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Brian McCallister wrote:

>> Properties can be read from a file (the current schema with 
>> OJB.properties) and from the System object as well as manipulated via 
>> generic setProperty/getProperty accessors.
>
> Consider also looking at Spring's BeanFactory -- we may be reinventing 
> things =) Making it basically bean configured opens up lots of 
> configuration options though -- could be Spring, JMX, Pico (sort of), 
> XML, etc with much fewer changes, particularly with the instance based 
> config you talk about.


The two schemes (from file / from 'System' object) were my initial ideas 
to make using OJB as painless as possible both in terms of migration and 
for new users. I'm not that familiar with Pico and the Spring 
configuration mechanism (though J�rgen H�ller gave me a couple of hints 
that I'll check), so I left them out. If you got ideas here (without OJB 
tying to Pico) than please post them !

>> Optionally, a schema can be employed that declares the properties 
>> that a particular component supports. For instance, a protected 
>> static string array in the component impl class can give the property 
>> names, which the configurator then reads out via reflection.
>
> Use a Properties object instead. This idiom has been established in 
> the javax.* abstract factories.


Thanks, I'll look into that.

>> In order to make OJB instance-based instead of singleton-based, a 
>> class should be introduced that is the central starting point within 
>> OJB, e.g. OJB.java. An instance of this class represents one running 
>> 'instance' of OJB, and multiple 'instances' of OJB can coexist within 
>> the same VM and thread (after we got rid of the singletons, including 
>> those for logging).
>
>
> Name conflict there with current ODMG. +1 for the idea.


Armin  and I were unsure about the name too (e.g. PersistenceManager is 
used by JDO). Any ideas ?

>> Both JCDs and models can be reused across PCs, e.g. copying objects 
>> from one db to another is accomplished by using the same model but a 
>> different connection descriptor.
>> As an additional enhancement, it should be possible to declare 
>> multiple SequenceManagers within one JCD (each with an unique 
>> identifier, and one being the default one).
>
>
> So, how would it handle multiple models (we need a better term, that 
> is too overloaded) against the same JCD? It would be a new PC instance 
> and separate configuration of OJB... Would caching be shared in any way?
>
> This starts to point to possible need for in-jvm "distributed" cache.


Since I don't really know anything about the inner workings of the cache 
mechanisms, I honestly can't say. Armin has probably some ideas here, 
though :-)

>> It should be possible to have JCDs and models in external, normal XML 
>> files, that are referred to in the PC declaration ('external-idref' 
>> attribute in the above example).
>
>
> if re-working large parts of this let's think hard about using a 
> schema to define it -- that would buy us a lot of things, not least of 
> which is much better write-time error checking capabilities. It also 
> would let us use something like XMLBeans to very easily make things 
> modifiable at run time as a compilation step instead of a maintained 
> chunk of code.


Hmm, interesting idea. Will have a look at XMLBeans.

>> Dynamic JCD-creation from JDBC urls
>> -----------------------------------
>>
>> To make using OJB easier esp. in web applications, a facility should 
>> be provided that allows to generate JCDs at runtime from jdbc url's 
>> (this includes identification of the platform). The implementation is 
>> not required to 'know' everything but should be able to handle the 
>> common cases (databases, drivers), since the generated JCD can be 
>> modified afterwards (e.g. setting a specific platform).
>
>
> This would more or less just be a lookup wouldn't it? Would dynamic 
> creation really occur, or just matching JDBC to PC via munging the 
> JDBC uri and interrogating registered configs?


This basically allows an application to use a jdbc url to manually 
create a JCD, but not more (though it might be useful to extend this to 
the JCD definition ?). The tricky part is to determine the Platform and 
(for db handling as described below) the database name, especially when 
using third-party drivers.

>> Persistent field configuration
>> ------------------------------
>>
>> The configuration of the PersistentField class to use for a given 
>> field should be moved from OJB.properties to the model because this 
>> is specific to a model. Also, it should be made both more simple and 
>> more flexible:
>
>
> Big big +1. Global configuration (OJB.properties) should specify the 
> defaults, though.


+1

>> Inheritance in the model
>> ------------------------
>>
>> The inheritance handling can be made easier and more comfortable with:
>>
>>   - deprecation/removal of the extent-concept in favour of the more 
>> Java-like extends-concept, i.e. a class-descriptor has an attribute 
>> 'extends' that specifies from which persistent classes it derives 
>> (multiple comma-separated values possible i.e. for interfaces)
>
>
> This works for me, though there are benefits to the extent model which 
> are subtle -- particularly when dealing with interfaces.


There seem to be problems with extents (see the recent threads about 
multiple-joined-tables-mapping and queries), and also the 
extends-concept is much more natural to Java developers IMO.

>> The metamodels of OJB (class/... descriptors) and of the XDoclet OJB 
>> module should be merged. This will make the constraints of the 
>> xdoclet module available for e.g. dynamic generation of the model at 
>> runtime.
>
>
> What does this actually entail? I am not familiar with the inner 
> workings of the XDoclet module.


Currently it has its own metamodel for the descriptors which I 
introduced to be independent from the XDoclet engine (which is only used 
for I/O). The module then checks several model constraints which should 
also be useful when building models at runtime.
Merging the two metamodels then simply removes duplication, and also has 
some other potential benefits when introducing annotation handling as 
sketched below.

>> A new helper class should be provided that allows easy creation of 
>> the metamodel at runtime from ordinary classes (via reflection 
>> 'magic' and the bean introspector).
>>
>> Java 1.5 annotations for OJB should be defined similar in naming and 
>> structure to the javadoc tags (as much as this is possible). This 
>> will require changes to the build process to enable building with JDK 
>> 1.5 while allowing to building with older JDKs (the annotation stuff 
>> is simply ignored then).
>
>
> Possibly, we should probably look also at the EJB3 annotations and the 
> (now discarded, from what I hear) JDO2 annotations to see if they had 
> any really good ideas. In general I fully agree with this approach 
> though. BTW -- we do compile and run fine under jdk1.5.


I already had a quick look at the EJB3 annotations, and they seem to be 
reduced Hibernate tags (i.e. only the semantic stuff). Supporting them 
directly should be no problem IMO (as an extension to the 
annotation-enhanced 'XDoclet' module).
With 'changes to the build process' I meant that we'll probably have to 
introduce another preprocessor flag for JDK1.5 as well as targets in the 
build.xml that are only evaluated when running under jdk1.5.

>> The XDoclet OJB module should be migrated from XDoclet to SGen which 
>> is a framework that can handle both Javadoc tags and annotations. In 
>> combination with the introduction of OJB annotations and the merged 
>> metamodels, this means that OJB can be used fully automatic:
>
>
>
> Make sure the community is okay with this. IIRC Sgen is a 
> single-developer project still (okay, xdoclet 1.X may be approaching a 
> 0 developer project, but...) with only Cedric contributing to and 
> maintaining it. He is a smart and hard working guy, but is just one 
> guy. Go see the cocoon "Building on Stone" thread for exhaustive 
> arguments about this type of thing.


XDoclet 1.x is actually alive and kicking (four or five active 
developers as far as I can tell) which can't be said of XDoclet 2.
But XDoclet has a lot of limitations and also is rather slow. You're 
right about SGen, though, but it might get some momentum (not unlikely 
given that Cedric is involved in the EJB3 process). While I think it 
would be easy to implement the stuff ourselves (with qdox and the java 
1.5 annotation api), I'd like to avoid this if possible and rather reuse 
from SGen.
 From the user's perspective, only the libraries required to run the 
module would change (xdoclet/xjavadoc -> sgen/dom4j), so that should be ok ?

>> Unit test setup
>> ---------------
>>
>> Unit tests should setup the database themselves to make them 
>> independent form each other. Also, the Torque stuff is quite 
>> complicated and fragile, so the idea is to provide a simple class for 
>> basic database operations like create, alter, drop, and for 
>> sql-generation for these operations. The unit tests then can use this 
>> db handling class and the new model facilities to easily setup the 
>> database in code.
>
>
> The performance aspect of this worries me. If we always use in-memory 
> this will get better though.


Perhaps we can test this idea with one of the more complex test 
scenarios when the db handling is ready to be used (which shouldn't take 
long anymore) ?

> Also, an Ant task should be provided that exposes the db handling 
> class, to replace the Torque stuff altogether [this is already in the 
> works].
>
> +1
>
> Has anyone looked at commons-sql? My understanding is that it was 
> looking to make a convenient interface for this type of thing. It was 
> abandoned last I looked.


AFAIK I'm the only active committer right now ;-) I spoke with Matthew 
Hawthorne and Thomas Mahler about migrating it to db-commons (havn't 
asked the PMCs yet, though), and I also will talk to the Torque guys 
about making a joint effort to create basic db-handling functionality in 
'db-commons'.

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org