Differences between revisions 17 and 18
Revision 17 as of 2004-09-26 08:47:36
Size: 8418
Comment:
Revision 18 as of 2009-09-20 22:56:16
Size: 8418
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 69: Line 69:
 * I think "native" JDO support should be in it -- ["JDOSupport"]  * I think "native" JDO support should be in it -- [[JDOSupport]]
Line 78: Line 78:
 * some restructuring would be nice ... e.g. move the reversedb stuff to it's own src dir and jar -- ["OJBTools"]  * some restructuring would be nice ... e.g. move the reversedb stuff to it's own src dir and jar -- [[OJBTools]]
Line 83: Line 83:
 * support for the complete ODMG 3 query language (OQL) as defined in their grammar -- ["OQLComplete"]  * support for the complete ODMG 3 query language (OQL) as defined in their grammar -- [[OQLComplete]]

Goals for OJB 1.0.1

  • fix unit tests failures for all databases that are supported by OJB

  • cleanup/update of documentation as necessary (e.g. Deployment)
  • completion of javadoc (incl. constants, parameters, return values, exceptions) for at least the public/protected API parts
  • look at tail recursions and remove where possible
    • [tomdz] Could you explaing what a tail recursion is and why it's important to remove them in 1.0.1 ?

      [rsfeir] This is a great link with example: http://www.refactoring.com/catalog/replaceRecursionWithIteration.html, to put it simply it's when the method keeps calling itself to iterate, instead of using while() or for() to process the information. The reason why you want it out is for greatly increased performance and better code readability. If you look at the current locations it's not always obvious what's going on. I know of about 40 some location the method calls itself, and imho that's not a good thing.

  • profile OJB 1.0 and determine areas of performance improvement
  • add IdentityFactory support to ease !Identity object creation

  • introduce PersistenceBrokerInternal (extends PersistenceBroker) to separate PB-api from the kernel. PBI allows to specify additional service methods for the top-level api without changing the !PB-api

  • first version of two-level caching

Goals for OJB 1.0.x

  • "Simple webapp with OJB" tutorial
  • Advanced inheritance tutorial/sample that shows:
    • interface + abstract base class
    • some sub-classes map to one table, others to their own tables
    • reference/collection to interface/abstract class
    • composite pattern
    • ojbConcreteClass
    • factory-class/factory-method + initialization-method
    • nested fields (?)
  • tutorials for how to use OJB with
    • Spring

      [tomdz] Jürgen Höller recently added initial OJB support to Spring, and he adapted the PetClinic sample to include OJB support. So OJB support wll be Spring 1.1 (August if I remember correctly). It would be good to have a simple tutorial that shows how to use OJB with Spring, e.g. a variant of the product-manager tutorial app

    • JBoss / Geronimo

      [tomdz] Armin volunteered for these

    • Struts

      [tomdz] I would do this one

    • JasperReports

  • generation of connection descriptors directly from jdbc url's (including the platform) for most common cases
    • [tomdz] I've already started this (see ConnectionRepository), but needs more refinement

  • creation and manipulation of databases with classes and ant tasks, based on commons-sql -- DatabaseManipulation

    • create db / alter db
    • drop db
    • dump data to XML
    • read data from XML
    • dump database structure (?)
    • [tomdz] IMO important enough to warrant introduction in 1.0.x. An initial version is already in CVS but needs more refinement and testing

  • tutorial on how to manage the database using dbhandling / torque / ant's sql task
  • rewrite batch handling, introduce BatchManager (needs kernel api changes, so maybe it's better to introduce this in 1.1)

Goals for OJB 1.1

  • I think "native" JDO support should be in it -- JDOSupport

    • [roberts] IMO Too aggressive for this release

  • support for McKoi and AxisDB databases -- SupportedDatabases

  • Better support for all kind of Java Collections and Maps. -- CollectionsAndMaps

  • support a real mapping of one class to multiple tables. -- OneClassMultipleTables

  • some restructuring would be nice ... e.g. move the reversedb stuff to it's own src dir and jar -- OJBTools

  • use jakarta-commons packages (e.g. logging and configuration) -- UseCommons

    • [tomdz] Esp. logging should replace the current logging handling of OJB; also commons-collections could be useful

  • support for the complete ODMG 3 query language (OQL) as defined in their grammar -- OQLComplete

  • documentation of OQL within OJB
  • getting rid of the singletons - runtime & configuration should be instance-based (important for integration with Spring and others)

  • reworking of the metamodel handling in OJB and XDoclet
    • merging of the two metamodels
    • new helper class that allows easy creation of the metamodel at runtime from classes (via reflection 'magic')
    • definition of Java 1.5 annotations for OJB (similar to the javadoc tags)
  • enhancement of connection/model configuration
    • introduction of PersistenceConfiguration (PC) that combines one JCD with one Model (descriptors) and defines additional mappings:

      • concrete sequence-managers to sequence-names used in the descriptors
      • concrete object-cache's to aliases used in the class descriptors
    • allow definition of multiple sequence managers in one JCD
    • easier runtime definition of JCD's and models
    • ability to use multiple PCs in the same VM

      [tomdz] This allows to truly separate model from connection description and to configure them together as needed

  • OJB configuration enhancements
    • should be doable completely at runtime (fully dynamic)
    • use of fully qualified property names that reflect bean properties of the configured component, e.g. org.apache.ojb.odmg.locking.LockManager.maxLocks

    • implementations are chosen via a *.class property, e.g. org.apache.ojb.odmg.locking.LockManager.class

    • the default values should be specified in the components, not in OJB.properties (-> usage of OJB without any external files)

  • ability to specify the used persistent field class per class descriptor/field descriptor
  • optional inheritance (controlled via a flag in the class descriptor) of feature descriptors between class descriptors which makes copying feature descriptors from super classes no longer necessary
  • deprecation of 'extent-class' in favour of an extends attribute for the sub-class descriptor (i.e. more like Java, but without the separation into Class/Interface)
  • full support mixing of mapping strategies. -- MixingMappingStrategies

Goals for OJB 1.x

  • support for generics (Java 1.5) -- JavaGenerics

  • support for jmx based run time management of broker management extc.

Unassigned goals

  • out-of-the-box support for storing primitive types. -- PrimitiveTypes

    • [tomdz] What is meant by that ?

  • completing the Prevayler based PB implementation. -- PrevaylerBroker

  • clear separation of API and SPI parts. In the ATM we this already, having it in the other layers as well ease the maintenance process, as OJB developers we'll immediately see which parts can be changed without changing parts of the API. -- ApiSpiSeparation

  • full support mixing of mapping strategies. -- MixingMappingStrategies (parts of it in OJB 1.1)

  • i'm playing with oracle spatial at the moment ... not sure if there is a way to support stuff like this .. but it would be nice ;-) -- OracleSpatial

    • [Martin Kalén] We (Curalia AB) have are back-end running in production that is reading and writing Oracle Spatial geometries using OJB (slightly-pre-)1.0 and OJB RowReaders with Oralce Spatial converters for convertering the STRUCT data. In a way OJB already supports spatial since the STRUCT datatype is supported. I don't think that geospatial functionality should be handled by OJB, there are many other OpenSource products handling this well.

  • I [thma] vote for removing support for the S.O.D.A query API (http://sodaquery.sourceforge.net/docs/index.html). I think we should focus on the standards like JDO and ODMG that have found some acceptance in the market.

  • Consistent handling of hints and aliases etc. for path-segments in Criteria. See http://nagoya.apache.org/eyebrowse/ReadMsg?listName=ojb-dev@db.apache.org&msgNo=7387 and http://nagoya.apache.org/scarab/issues/id/OJB293

There are a large number of features proposed for the 1.1 release, it reads more like a wish list than feature list :) Why not schedule a number of releases 1.1, 1.2, 1.n, 1.n+ that deliver features based on priority??? I'm sure more users out there care about a JDO implementation than some other features especially now that JD02 is on the way. Besides its much easier to make many smaller releases than a few large ones and should improve the credibility of this fine project. --AndyHull

OJBNextSteps (last edited 2009-09-20 22:56:16 by localhost)