db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: ojb 1.1 ideas and proposals
Date Mon, 12 Jul 2004 15:24:23 GMT
hi thomas,

this is quite a lot for 1.1 ;)

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


Mime
View raw message