>
>
> 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.
i had intended to this myself and will this weekend.
>
> 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.
I'm not sure i follow you on this could explain a bit more? I understand the
"...should ideally have no
> business meaning therefore it should not change..." part and the "...The
singular purpose of
> the OID is to uniquely identify the object in our DB..." part but i don't
see how the setting of the OID "...could corrupt the uniqueness of the
OID..." part. and the "...we get an error because we are trying to save a
duplicate key..." part. AFAIK, the OID is used to create an intelligent key
and once assigned to a record, that record will always use that same key aka
OID.
> 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.
This is a great idea, the design says that there are the only classes the
application programmer needs to know about are: PersistentObject,
PersistentCriteria class hierarchy, PersistentTransaction and Cursor, thus
defining the API. I will be rearranging the package structure over this up
coming weekend.
> 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.
Whoa, i don't think i agree with this but i don't have the time right now to
explain (i'm late for work <g>) i will follow-up with you tonight.
-scott-
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
