Fwd: [Apache JDO Wiki] New: DefaultMappingMetadata

[Craig Russell <Cr...@Sun.COM>]

Hi Michelle,

Can you take a look at this (old) message and make sure we have 
everything covered?

Thanks,

Craig

Begin forwarded message:

> From: Abe White <aw...@solarmetric.com>
> Date: February 9, 2005 3:30:08 PM PST
> To: JDO Expert Group <jd...@sun.com>
> Cc: jdo-tck-ext@sun.com
> Subject: Re: [Apache JDO Wiki] New:  DefaultMappingMetadata
>
> I only glanced at the UML model and I haven't looked at the schema, 
> but some comments inline.  Note that I don't know whether some of the 
> errors / weirdness I point out below is on purpose to test things...
>
>>> <class name="Address" table="address"/>
>
> Without mapping the fields, the mapping isn't valid.  So why name a 
> table for it?  If addresses don't exist unless embedded, then use 
> <class name="Address" embedded-only="true"/>.   Or at least use an 
> inheritance strategy of "no-table" and get rid of the table attribute.
>
>>>         <class name="Department" table="departments">
>>>             <field name="deptid" column="id"/>
>>>             <field name="name" column="name"/>
>>>             <field name="company" column="companyid"/>
>>>             <field name="employees" mapped-by="department">
>>>                 <foreign-key/>
>>>             </field>
>
> The "department" field defines the mapping for "employees", so 
> employees cannot declare a foreign key -- only department can define 
> the foreign key properties.
>
>>>   <class name="Employee" table="employees">
>>>             <inheritance strategy="new-table">
>>>                 <discriminator strategy="classname" 
>>> column="discriminator"/>
>>>             </inheritance>
>
> "classname" is not a valid discriminator strategy.  Should be 
> "class-name".  Or you can leave it unspecified, since I believe that 
> is the default.
>
>>>             <field name="hiredate" column="hiredate"/>
>>>             <field name="weeklyhours" column="weeklyhours"/>
>>>             <field name="dentalInsurance" column="dentalinsurance">
>>>                 <foreign-key/>
>>>             </field>
>>>             <field name="medicalInsurance" column="medicalinsurance">
>>>                 <foreign-key/>
>>>             </field>
>>>             <field name="department" column="department">
>>>                 <foreign-key/>
>>>             </field>
>>>             <field name="fundingDept" column="fundingdept">
>>>                 <foreign-key/>
>>>             </field>
>>>             <field name="manager" column="manager">
>>>                 <foreign-key/>
>>>             </field>
>>>             <field name="mentor" column="mentor">
>>>                 <foreign-key/>
>>>             </field>
>>>             <field name="protege" column="protege">
>>>                 <foreign-key/>
>>>             </field>
>>>             <field name="hradvisor" column="hradvisor">
>>>                 <foreign-key/>
>>>             </field>
>
> You can use <field name="xxx" column="yyy" delete-action="restrict"/> 
> as an equivalent to the empty foreign key elements if you want.  
> Either way.
>
>>> <class name="Insurance" table="insuranceplans">
>>>             <inheritance strategy="new-table">
>>>                 <discriminator strategy="classname" 
>>> column="discriminator"/>
>>>             <inheritance/>
>>>             <field name="insid" column="insid"/>
>>>             <field name="carrier" column="carrier"/>
>>>             <field name="employee" mapped-by="dentalInsurance"/>
>>>             <field name="employee" mapped-by="medicalInsurance"/>
>>>         </class>
>
> You can't map the "employee" field twice.
>
>>>         <class name="PartTimeEmployee" table="employees">
>>>             <inheritance strategy="superclass-table"/>
>>>         </class>
>
> No need to use the table attribute if you use superclass-table 
> inheritance strategy, though it is allowed.
>
>>>         <class name="Person" table="employees">
>>>             <inheritance strategy="no-table"/>
>
> You can't name a table for a class that isn't supposed to have a table.
>
>>>             <field name="middlename"/>
>>>             <field name="address">
>>>                 <embedded>
>>>                     <field name="street" column="street"/>
>>>                     <field name="city" column="city"/>
>>>                     <field name="state" column="state"/>
>>>                     <field name="zipcode" column="zipcode"/>
>>>                     <field name="country" column="country"/>
>>>                 </embedded>
>>>             </field>
>
> I don't think you should be allowed to map any fields of a class with 
> "no-table" strategy.  What are you mapping to?
>
>>>     	    <field name="phoneNumbers" >
>>>                 <join table="employee_phoneno_type" 
>>> column="personid" target="empid"/>
>>>                 <key column="type"/>
>>>                 <value column="phoneno"/>
>
> The table attribute is only valid on class-level <join> elements used 
> to represent a shared join to a secondary table.  Whenever a field is 
> mapped to another table, use the table attribute on <field>.  The join 
> element also does not have a target attribute.  So this mapping 
> overall should look like:
> <field name="phoneNumbers" table="employee_phoneno_type">
>     <join column="personid"/>
>     <key column="type"/>
>     <value column="phoneno"/>
> </field>
>
> Or if empid is not the only pk column of the owning class, and the 
> target therefore needs to be explicit:
> <field name="phoneNumbers" table="employee_phoneno_type">
>     <join>
>         <column name="personid" target="empid"/>
>     </join>
>     <key column="type"/>
>     <value column="phoneno"/>
> </field>
>
> And once again, you can't map fields of a class that uses "no-table" 
> strategy.  I don't really know what you guys are trying to do here.  
> Why not make Person use "new-table" and make Employee use 
> "superclass-table"?  (In that case Person should also be the class to 
> define the discriminator.)  That way Person can map its own fields.  
> If you don't do that, and you're intent on Person being "no-table", 
> then Employee has to be the one to map Person's fields, since Employee 
> is the one mapped to a table.  So Employee would map the fields you're 
> trying to map in Person above, and also fields like "firstName", 
> "lastName", and "middleName" which right now are completely unmapped.  
>  Employee would look like:
> <class name="Employee">
>     ...
>     <field name="Person.firstName" column="xxx"/>
>     <field name="Person.address">
>         <embedded>
>             <field name="street" column="street"/>
>              ...
> </class>
>
>>> <class name="Project" table="projects">
>>>             <field name="projid" column="projid"/>
>>>             <field name="name" column="name"/>
>>>             <field name="budget" column="budget"/>
>>>             <field name="reviewers">
>>>                 <join table="project_reviewer" column="projid"/>
>>>                 <element column="reviewer">
>>>             </field>
>>>             <field name="members">
>>>                 <join table="project_member" column="projid"/>
>>>                 <element column="member"/>
>>>             </field>
>
> My comments for "phoneNumbers" on how field joins work also apply to 
> "reviewers" and "members" above.  Namely, move the "table" attribute 
> from the join element up to the field element.
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!