Hi Stein,

The change you made certainly has some benefits, for I've been in the position where 
I've been force to stub out a set-method to comply with this feature.  The way you've 
implemented the change may be a little dangerous since it doesn't do the checking at 
all now.  

A cleaner approach would be to make the get/set method checking a property of castor 
and then perform the check according to the value of the property.  The caveat to 
making the checking a property is to determine at what level the property is applied.  
To specify it in the castor properties file may be a bit too large scale, but 
specifying it at the field, class or mapping file level requires modifying the 
corresponding dtd.

Does any one else have any thoughts on this?

-----Original Message-----
From: Stein M. Eliassen [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 24, 2003 2:51 PM
To: [EMAIL PROTECTED]
Subject: [castor-dev] A couple of hacks


Hi there!

I made a couple of hacks to Castor-0.9.5 so I don't need to specify a 
set-method and xml-only fields are not attempted loaded in types mapped 
to both table and xml.

Here is an example-mapping:

<class name="Course" auto-complete="false" identity="ID" 
key-generator="IDENTITY">
        <cache-type type="time-limited" capacity="3600"/>
        <map-to table="course" xml="course"/>
        <field name="ID" type="integer" key-generator="identity">
                <sql name="course_id"/>
                <bind-xml name="course_id"/>
        </field>
        <field name="startWeek" type="integer">
                <sql name="start_week"/>
                <bind-xml name="start_week"/>
        </field>
        <field name="startYear" type="integer">
                <sql name="start_year"/>
                <bind-xml name="start_year"/>
        </field>
        <field name="startDate" type="date" get-method="getStartDate">
                <bind-xml name="start"/>
        </field>
</class>

startDate is just a get-method, set at runtime from startWeek and 
startYear and thus not stored in the database.

Instead of throwing an exception in FieldMolder when it can't find a 
set-method I've just commented out the throw-clause (In the Constructor 
and setValue).

The other hack is in the SQLEngine-constructor and it now only test for 
JDOFieldDescriptor-type:
if (fieldDescriptors[i] instanceof JDOFieldDescriptor /*&& 
(fieldDescriptors[i].getClassDescriptor() != null) */)

Any comments and/or alternative methods of doing this?

Stein

----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

Reply via email to