jvanzyl 01/11/12 12:14:56
Modified: . build-test.xml
Added: . NOTES.txt
Removed: . NOTES
Log:
- change name of NOTES file to try and work around possible windows problem.
Revision Changes Path
1.16 +0 -3 jakarta-turbine-torque/build-test.xml
Index: build-test.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine-torque/build-test.xml,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- build-test.xml 2001/11/08 04:36:11 1.15
+++ build-test.xml 2001/11/12 20:14:56 1.16
@@ -46,9 +46,6 @@
overwrite="yes">
<fileset dir="${rttest.dir}">
<include name="**/*.xml"/>
- <!-- exclude this for now because getting this
- to work with all the databases will be a lot of work -->
- <exclude name="**/type-test-schema.xml"/>
</fileset>
</copy>
1.1 jakarta-turbine-torque/NOTES.txt
Index: NOTES.txt
===================================================================
--------------------------------------------------------------------------
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
the struts connection pool or whatever
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
use the digester with MinML so that the distribution can
be tiny
o Some analysis on what we actually have would be prudent. Torque
is somewhat based on the work of Scott Ambler and I would like
to know where it is the same and where it diverges so we know
what we're dealing with.
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,
enough to identify the object. you might use the proxy
objects in a list and when it is selected the real user
object is transparently retrieved.
[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 handled in the JDBC layer.
o application programmers should be able to save, update, and
delete objects without any knowledge of the database schema.
if the attribute selection is based on columns in tables than
the object hierarchy and database schema cannot vary
independently. it is likely that the database schema may need
to change but you don't want this to affect application
programmers who may know little about databases. reasonably
so, the persistence layer should take care of everything.
[JSS] YES!
Questions
---------
These are really just questions I'm jotting down as I go through
the source. Not really important that they be answered here, I'll
post the whole slew to the list eventually.
o Why is there a save(DBConnection) in the BaseObject?
The objects should know nothing about databases, and if knowledge
of a specific database is required it should probably be in
some mapping mechanism. The BaseObject should be retrievable
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.
o Why do we have so many key types. I thought the surrogate key
idea was better? That the keys for objects should have no business
meaning under any circumstance. This practice is strongly warned
against in Ambler's papers. The object key should be a number or
a string.
o Why does the TableMap make reference to the IDGenerator? I realize
the id method can be specifed on a table basis. Maybe the datamodel
object could be used at run time as the source of information about
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?
----
Get rid of ${torque.home} in the standard build.xml files and define
all the possible values that can be set and document them so that
people can use the standard build.xml file in a known way. Things
are a little loosy-goosy and fragile right now. What I do could still
potentially break scarab's build because I'm not sure how things
are being used ... but I'm getting there :-)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
