Hello Scott,
Just downloaded the latest Scott Ambler white paper and the code you have been
working on. Looks good. I have checked out the PersistentObject and some
of the mapping code. I cant say that I fully understand the maps just yet
but here are some comments on the PersistentObject and basic create,
retrieve, update and delete.
Is it necessary to have the following methods in PersistentObject?
1 getSqlSelect()
2 getSqlUpdate()
3 getSqlInsert()
4 getColumnNameForAttribute()
5 setOID()
My reasoning for wanting to take methods (1-4) out are that they directly
expose the SQL layer we are trying to encapsulate. In Scott Ambler's white
paper he said the persitent object is "fairly simple" having only three
methods. We could defer these 4 methods to 3 separate instances
of SqlStatement.
The reasoning for not having a setOID is that an OID should ideally have no
business meaning therefore it should not change. The singular purpose of
the OID
is to uniquely identify the object in our DB. If we get into setting the OID
we could corrupt the uniqueness of the OID. This problem would not manifest
itself until we saved the object. Hopefully, if the DBAs have the tables
keyed correctly we get an error because we are trying to save a duplicate
key.
Another thing and this could be splitting hairs is package naming. I would
prefer that we not use the package name org.apache.turbine.opl.sql. Instead
I would prefer a package structure where all publicly used classes are
put into an api package structure. This way we can say to the application
programmer
'If you are using classes outside this api structure, you are not using the
opl right.' I thought of calling this structure include, but think I prefer
api.
The rest of the functionality added to PersistentObject seems ok.
Have you thought of how we are going to access private member values from
the PersistentObject's subclasses so we can save them in the database. There
really is no way AFAIK around accessing the private member data without
at least a little help from the application programmer. The least intrusive
way
I found was serialization. I have written a serialization protocol
implementation to extract
the data from the subclass instances.
I did not write the serialization protocol implementation in one day :). It
was
from an implementation of an object persistence layer I called objrel, which
I will hopefully post today on my website. Objrel was based on the first
white paper written by Scott Ambler. It is not nearly as flexible as the
outline from Scotts latest white paper.
Jeff Prickett
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
