cvs commit: jakarta-turbine-torque build-test.xml NOTES.txt

[mp...@apache.org]

mpoeschl    2002/12/29 10:21:53

  Modified:    .        build-test.xml NOTES.txt
  Log:
  the runtime tests now include the generation of ojb stuff
  
  Revision  Changes    Path
  1.41      +10 -0     jakarta-turbine-torque/build-test.xml
  
  Index: build-test.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-turbine-torque/build-test.xml,v
  retrieving revision 1.40
  retrieving revision 1.41
  diff -u -r1.40 -r1.41
  --- build-test.xml	14 Dec 2002 15:33:54 -0000	1.40
  +++ build-test.xml	29 Dec 2002 18:21:53 -0000	1.41
  @@ -114,6 +114,7 @@
       <antcall target="test-id-table-init-sql"/>
       <antcall target="test-insert-sql"/>
       <antcall target="test-om"/>
  +    <antcall target="test-ojb"/>
     </target>
   
     <!-- ============================================================== -->
  @@ -243,6 +244,15 @@
         antfile="${torque.buildFile}"
         target="jdbc">
         <property name="torque.home" value="${torque.distDir}"/>
  +    </ant>
  +  </target>
  +
  +  <target
  +    name="test-ojb">
  +    <ant
  +      dir="${torque.buildFileDir}"
  +      antfile="${torque.buildFile}"
  +      target="ojb">
       </ant>
     </target>
   
  
  
  
  1.4       +10 -17    jakarta-turbine-torque/NOTES.txt
  
  Index: NOTES.txt
  ===================================================================
  RCS file: /home/cvs/jakarta-turbine-torque/NOTES.txt,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- NOTES.txt	9 Mar 2002 01:39:52 -0000	1.3
  +++ NOTES.txt	29 Dec 2002 18:21:53 -0000	1.4
  @@ -2,13 +2,6 @@
   T O R Q U E
   --------------------------------------------------------------------------
   
  -o Torque should be fully functional on its own, but right now
  -  it doesn't work as a persistence layer without the DBService
  -  in Fulcrum. The classes should be moved from Fulcrum into
  -  this repository and Torque should be made to work on its own
  -  and be embeddable in applications. The DBService in Fulcrum
  -  should be a wrapper around Torque.
  -
   o Separate the connection pool and make it pluggable
     so that torque can easily be integrated into other application
     that already use PoolMan, or the commons connection pool, or
  @@ -17,7 +10,7 @@
   o XML as configuration
   
   o Use the digester to turn the datamodel into an object and
  -  get rid of the dependency on xerces. It would be nice to 
  +  get rid of the dependency on xerces. It would be nice to
     use the digester with MinML so that the distribution can
     be tiny
   
  @@ -28,20 +21,20 @@
   
   o find all other OSS persistence layer projects and see if
     we can join forces.
  -  
  +
   o separate the runtime system from the generation tools, place
     them in different packages.
   
   o using cursors to allow controlled access to a large set
     of data. typically there is no need to see a massive
     set of records all at once.
  -  
  +
     [JSS] Not really database agnostic though. Must be implemented
     conditionally.
  -  
  +
     [JVZ] But it has to be made to work transparently. The specifics
     should be in the RDB specific object. The adapter probably.
  -  
  +
   o using proxies for large objects. if you had a user object
     that had 50 attributes it would more efficient to create
     a proxy object of that user that might have a few attributes,
  @@ -51,13 +44,13 @@
   
     [JSS] I consider this custom code and can be implemented in
     the base objects quite easily.
  -  
  +
   o would it be possible to support native connection methods
     for high efficiency. an easy to access C APIs, would it
     even be useful?
   
     [JSS] in this case, the JDBC driver can be made native and
  -  is probably not a worry/optimization of ours because this 
  +  is probably not a worry/optimization of ours because this
     is handled in the JDBC layer.
   
   o application programmers should be able to save, update, and
  @@ -85,7 +78,7 @@
     from any store so the BaseObject shouldn't contain information
     about any specific store type. XML persistence would be nice
     to add with one of myriad tools that exist.
  -  
  +
   o Same question for the the Persistent interface. Would be nice
     to get rid of the DB specifics.
   
  @@ -101,12 +94,12 @@
     the database setup. Than a lot of the objects that are coupled could
     be decoupled because all the meta info would be present in the
     datamodel object.
  -  
  +
   o Same goes for the DatabaseMap. We definitely have information duplicated
     across objects. Most of this info is already present in the datamodel
     used to produce the OM. Could use the datamodel to decouple which is
     what would be need to have pluggable connection pools.
  -  
  +
   o Could the information in the adapters be coupled with information
     in the db.props file and combined into some XML descriptor for
     database specifics?