db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: ojb 1.1 ideas and proposals
Date Mon, 12 Jul 2004 11:16:45 GMT

On Jul 10, 2004, at 1:59 PM, Thomas Dudziak wrote:

> Property names should be qualified to ease integration with other apps 
> that use properties (avoiding name clashes and making it easy to 
> identify where the property belongs). Also, the settings should be 
> stored in the configured components (decentralized) - this includes 
> the default values.


> To qualify the property names, the fully qualified class name of the 
> component (its facade, or abstract base class) plus the name of the 
> property can be used, e.g. 
> "org.apache.ojb.odmg.locking.LockManager.timeout".
> Concrete components (for example the lock manager) are specified via 
> the special 'class' property, e.g. 
> 'org.apache.ojb.odmg.locking.LockManager.class' (instead of 
> 'LockManagerClass').


also makes "sort OJB.properties > OJB.temp && mv OJB.temp 
OJB.properties" work nicely =)

> With the qualified property names, the configuration implementation 
> now can simply use the property name to set the property at the 
> component via relection. This eases the integration of new components 
> or change of existing ones because only the component itself must be 
> changed (as well as the documentation of it), but not the 
> configuration mechanism.

Good call!

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

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

> Instance-based OJB
> ------------------
> To allow for better integration with Spring and for a JDO impl, OJB 
> should be instance-based (no singletons, incl. the logs) and fully 
> configurable at runtime (no explicit need for OJB.properties and 
> repository.xml). The latter could be achieved via the central 
> configurator object from the last paragraph, and via metamodel 
> creation at runtime (see next paragraph)

+1 !!

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


> Connection & Model
> ------------------
> The connection settings (JCDs etc.) and the model (class descriptors 
> etc.) should be completely separated (the latter independent of the 
> used connection/database) in order to
>   - support multiple connection+model combinations within the same 
> 'instance' of OJB
>   - support multiple instances of OJB in the same VM/thread that may 
> also share JCDs and/or models (readonly with clone-on-change)
> For this, a new new top-level configuration item should be introduced 
> called PersistenceConfiguration (PC). It combines exactly one 
> connection descriptor (JCD) with one model (which is also an explicit 
> tag in the XML file, see example below). The 'OJB' object then manages 
> one or more PCs which are identified via a PCKey (which supercedes the 
> PBKey).

+0 Need to think about ramifications, but I think I like it.

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

> In addition to combining one JCD and one model, the PC contains 
> mappings for:
>   - sequence manager (JCD) -> sequence name (Model)
>   - object cache (JCD) -> class descriptor (Model)

Answers my earlier question =)

> and perhaps additional stuff (like insert/update/delete procedure 
> mappings ?).

This is part of class mapping and should remain there, I think.

> Example of a repository.xml:


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

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

> [I have already started this (see ConnectionRepository) but it needs 
> more work. Especially, deciphering the jdbc url may be platform 
> specific.]

Cool =)

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


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

>   - an additional attribute 'inherit-features' that allows the control 
> of automatic inheritance of features from the base classes (default: 
> true), e.g. OJB copies the feature descriptors into the class 
> descriptor upon loading/definition of the model)

I like.

> Also, 'extends' should be used regardless of the mapping scheme 
> (subclasses to one table or to multiple joined tables) because OJB has 
> other means to identify which scheme is used (ojbConcreteClass and 
> super-references).

Consistency good.

> Example:


> Internal model handling
> -----------------------
> ObjectReferenceDescriptor should be renamed to ReferenceDescriptor.

+1 !!

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

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

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

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

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


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.


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

View raw message