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 17:49:58 GMT

On Jul 12, 2004, at 11:24 AM, Jakob Braeuchi wrote:

> hi thomas,
> this is quite a lot for 1.1 ;)

I agree that this may be scoped beyond 1.1 based on fixed time, 
variable scope, release planning ;-)

Any estimates on how much needs to be done for these things?


> Thomas Dudziak wrote:
>> (Sorry for the rather long mail but I hope it is worthwhile :-)
>> Armin and I were discussing about enhancements for OJB 1.1, and we 
>> came up with a list of ideas and proposals. Most of them are already 
>> on the wiki page in a shorter form, but we thought it makes sense to 
>> present them in more detail for discussion. So without further ado 
>> ...
>> OJB property mechanism
>> ----------------------
>> 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').
>> This allows easy mixing of generic properties of a component (e.g. 
>> "org.apache.ojb.odmg.locking.LockManager.timeout" - the accessors for 
>> this property would be specified in the LockManager interface) and 
>> specific lock manager implementations (e.g. 
>> "org.apache.ojb.odmg.locking.LockManagerDefaultImpl.someProperty")
> +1
>> 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.
>> 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.
>> 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.
>> 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)
>> 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).
> +1
>> The 'OJB' class is then primarily used to:
>>   - configure OJB and access connection descriptors/metamodel 
>> (properties, logging setup, persistence configurations - see below) 
>> via corresponding classes
>>   - obtain broker instances (what currently is done directly via the 
>> PersistenceBrokerFactory), both the default one and per lookup via PC 
>> names (see below)
>> 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).
>> 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).
>> 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)
>> and perhaps additional stuff (like insert/update/delete procedure 
>> mappings ?).
>> Example of a repository.xml:
>>   <ojb-configuration>
>>     <jdbc-connection-descriptor id="db1" ...>
>>         <sequence-manager id="default" .../>
>>         <sequence-manager id="otherSeqMan" .../>
>>         <object-cache id="cache-key" .../>
>>     </jdbc-connection-descriptor id="db1">
>>     <model id="default">
>>       ...
>>     </model>
>>     <persistence-configuration id="default">
>>       <jdbc-connection-descriptor idref="db1"/>
>>       <model idref="default"/>
>>       <mappings>
>>         <sequence-mapping sequence-name="mySeq" idref="otherSeqMan"/>
>>         <cache-mapping class-ref="MyClass" idref="cache-key"/>
>>       </mappings>
>>     </persistence-configuration>
>>     <persistence-configuration id="guest">
>>       <jdbc-connection-descriptor 
>> external-idref="repository_user.xml#db2"/>
>>       <model>
>>         ...
>>       </model>
>>     </persistence-configuration>
>>   </ojb-configuration>
>> 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).
>> 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).
>> [I have already started this (see ConnectionRepository) but it needs 
>> more work. Especially, deciphering the jdbc url may be platform 
>> specific.]
>> 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:
>>   - allow specification of the impl class for the complete model, a 
>> single class or even a single field
>>   - remove the need to specify the impl class for the common cases, 
>> i.e. direct access, bean property
>> For this the following changes could be made to the descriptors:
>>   - two new attributes for the model (stating the default value for 
>> all fields), for class descriptors (the default value for all fields 
>> of this class overriding the model setting) and field descriptors 
>> (only for this field) :
>>      * 'field-type' stating the kind of field: 'field', 'property', 
>> etc. (with 'field' the default value) -> OJB automatically uses the 
>> corresponding PersistentField impl
>>      * 'field-class' allows to specify the persistent field class 
>> (e.g. for user-defined implementations)
> +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 is more JDO like, but i think there's no big advantage.
>>   - 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)
> +1 the users will like it ! but it should be possible to override a 
> field in the subclass.
>> 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).
> i'd prefer to drop the super-references and replace it with a real 
> mapping of one class to multiple tables.
>> Example:
>> Instead of
>> <class-descriptor class="test.A">
>>     <extent-class class-ref="test.C"/>
>> </class-descriptor>
>> <class-descriptor class="test.B" table="B">
>>     <extent-class class-ref="test.C"/>
>>     <field-descriptor
>>         name="id"
>>         column="id"
>>         jdbc-type="INTEGER"
>>         primarykey="true"/>
>> </class-descriptor>
>> <class-descriptor class="test.C" table="C">
>>     <field-descriptor
>>         name="id"
>>         column="id"
>>         jdbc-type="INTEGER"
>>         primarykey="true"/>
>>     <field-descriptor
>>         name="aid"
>>         column="aid"
>>         jdbc-type="INTEGER"/>
>>     <field-descriptor
>>         name="ojbConcreteClass"
>>         column="ojbConcreteClass"
>>         jdbc-type="VARCHAR"
>>         length="254"/>
>> </class-descriptor>
>> the model could be written as
>> <class-descriptor class="test.A"/>
>> <class-descriptor class="test.B" table="B">
>>     <field-descriptor
>>         name="id"
>>         column="id"
>>         jdbc-type="INTEGER"
>>         primarykey="true"/>
>> </class-descriptor>
>> <class-descriptor class="test.C" table="C" extends="test.A,test.B">
>>     <field-descriptor
>>         name="aid"
>>         column="aid"
>>         jdbc-type="INTEGER"/>
>>     <field-descriptor
>>         name="ojbConcreteClass"
>>         column="ojbConcreteClass"
>>         jdbc-type="VARCHAR"
>>         length="254"/>
>> </class-descriptor>
>> where the class-descriptor of test.C automatically inherits the 
>> primary key field from test.B.
>> Internal model handling
>> -----------------------
>> ObjectReferenceDescriptor should be renamed to ReferenceDescriptor.
>> 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.
>> 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).
>> 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:
>>   - configuration of OJB at runtime
>>   - definition of the connection at runtime
>>   - generation of the model at runtime from the annotated classes
>> Unit test setup
>> ---------------
>> Unit tests should setup the database themselves to make them 
>> independent
> ++1
> jakob
>> 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.
>> 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].
>> regards,
>> Tom
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org

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

View raw message