db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ludovic Maitre (POP - Factory Part)" <lmai...@factory-part.com>
Subject Re: Referencing an abstract class. The next turn...
Date Thu, 14 Oct 2004 09:18:40 GMT
Hello Armin,

I'm really sorry, perhaps my posts are off topics... It seems that the 
patches doesn't require the extends attribute. But they adress, i think, 
the problem of retrieving child objects with the properties of the super 
class populated.

To use the patchs the descriptory must be build with our "rules" (at 
least this is with this setup that we test) :
- a parent class has a class descriptor, and the fields of this class 
are stored in a db table. All the childs objects are declared as extend 
class (see below) of the object.
- a child class is stored in is own table, which contain only the 
"childs" fields. Also we set the superClass of the child class to be the 
parent class (but this is not reflected by the toXML() method of the 
class descriptors, it seems, see below).
- we do not use compound primary keys. We use simple primary keys, which 
are the same property on the child and the parent object. Our primary 
key are of stored as INT(11) and are mapped to a property "id". This 
property is declared in the parent and the child class descriptors. The 
other fields of the parent are not declared in the child class 
descriptor. We redeclare id because we want to have a primary key class 
for the child object.

<field-descriptor access="readwrite" column="ID_OBJ" 
conversion="fr.factory.ojb.conversions.Integer2LongFieldConversion" 
jdbc-type="INTEGER" name="id" primarykey="true"/>

 Only the extent-class attribute on the parent object and another 
attribute that i haven't had the time to identify for the moment are used.
When i generate my class descriptors from my metadatas, i do the following :
...
        if (dao.getType().getSuperclass() != Object.class
                && !ArrayUtils.contains(excludedClasses, dao.getType()
                        
.getSuperclass().getName())&&BeanFactory.hasInstance(dao.getType().getSuperclass()))

{
            Helper.debug("Set super class to 
"+dao.getType().getSuperclass().getName()+" for name");
            e.setSuperClass(dao.getType().getSuperclass().getName());
        }
...
It seems that this is not reflected in the sample class descriptors, but 
i don't know why for the moment (and i don't know to what the property 
superClass is mapped, but sure you know ;-).

Also i use this for generate the extent-class attributes:

    public synchronized void prepareExtends() {
//class extends is a map with the parent class name as keys and a 
collection of child class name as value
        Iterator i = classExtends.keySet().iterator();
        while (i.hasNext()) {
            String parentName = (String) i.next();
            Collection childs = (Collection) classExtends.get(parentName);
            log.debug("Preparing extends for '" + parentName + "'. There 
is "
                    + childs.size() + " childrens.");
            ClassDescriptor parent = (ClassDescriptor) 
classes.get(parentName);
            //parent could be not persistent
            if (parent!=null) {
            Iterator j = childs.iterator();
            while (j.hasNext()) {
                String childName = (String) j.next();
                log.debug("Adding '" + childName + "'.");
                parent.addExtentClass(childName);
                /* Not used:
                 * ClassDescriptor childCld = (ClassDescriptor)
                 * classes.get(childName);
                 *
                 * ObjectReferenceDescriptor ord = new
                 * ObjectReferenceDescriptor(childCld);
                 * ord.setPersistentField(Long.class,"super");
                 * ord.addForeignKeyField("id");
                 * ord.setItemClass(parent.getClassOfObject());
                 * ord.setCascadeRetrieve(true);
                 * 
ord.setCascadingStore(ObjectReferenceDescriptor.CASCADE_OBJECT);
                 * 
ord.setCascadingDelete(ObjectReferenceDescriptor.CASCADE_OBJECT);
                 */
            }
            }
        }
    }

Also if i remember correctly, the following patch help to determine 
which class is instantiated (but i have forgotten why, and what is the 
difference with isAssignableFrom):

    //LMA
    private boolean isEqualOrAncestor(Class a,Class b) {
        if (a==null||b==null)
            return false;
        if (a.equals(b))
            return true;
        if (b.getSuperclass()!=Object.class)
            return isEqualOrAncestor(a,b.getSuperclass());
        return false;
    }
   
    /**
     * Answer the real ClassDescriptor for anObj
     * ie. aCld may be an Interface of anObj, so the cld for anObj is 
returned
     */
    private ClassDescriptor getRealClassDescriptor(ClassDescriptor aCld, 
Object anObj)
    {
        ClassDescriptor result;
        //LMA
        if(isEqualOrAncestor(aCld.getClassOfObject(),anObj.getClass()))
        {
            result = aCld;
        }
        else
        {
            result = 
aCld.getRepository().getDescriptorFor(anObj.getClass());
        }

        return result;
    }

Armin Waibel wrote:

> Hi Ludo,
>
> I have problems to make the inheritance tests run with a patched 
> version of OJB and the "extends"-attribute.
> Seems I have problems with the mapping, but your examples do not use 
> "extends" attribute
> http://dev.factory-part.com/oss/ojb/samples/objects.html
>
> How should the mapping look like when using patched "extends" version?
> I try to run a modified version of InheritanceMultipleTableTest.java 
> (this test originally use "super"-references to build the inheritance) 
> from test suite with new mapping and the "extends"-attribute.
>
> Employee<---Executive<---Manager using a compound PK (id Integer, id_2 
> Long) and Company has a 1:n reference with Employee base class.
>
> It seems that we will get the same problems as with 
> "super"-references. If I store an Company object with an Manager 
> object in Company's employees collection, the object was correctly 
> stored.
> But if I read the Company object from DB the employee collection only 
> contains one object of type Employee instead of Manager - I'm wrong?
>
> regards,
> Armin
>
>
> Ludovic Maitre (POP - Factory Part) wrote:
>
>> Hello,
>>
>> When you have this testcase or he have been put in cvs, i suppose 
>> that our modified version of OJB (with the patch indicated at
>> http://dev.factory-part.com/oss/ojb ) could pass it without 
>> problems.  We have designed our modifications to OJB source code for 
>> this purpose (handling inhreitance over multiple tables, and 
>> returning the child objects instances with child objects also 
>> populated with fields from super class).
>> I agree that our patches are not very nice and should be improved 
>> before integration in ojb, but the ideas are here (and work in our 
>> context).
>> So, if some of the experts of OJB could see if theses patchs solves 
>> this issue, and especially if their is a way to introduce them in the 
>> source base without breaking the other test cases, it will be nice.
>> Have a good day,
>> Ludo
>>
>> Armin Waibel wrote:
>>
>>>
>>>
>>> Carsten Spräner_Ext wrote:
>>>
>>>> Hi Armin,
>>>>
>>>> i looked at the test ojb....broker.InheritanceMultipleTableTest and 
>>>> didn't
>>>> find a place where you do a query to an Employee and than do a cast 
>>>> to, for
>>>> example, Manager. But that's exactly what i need. When mapping all 
>>>> classes
>>>> in one table this is possible. The test case should be:
>>>>
>>>>  1. query for all Employees where name like 'manager'. But create 
>>>> the query
>>>> with Employee.class.
>>>>  2. assert that all loaded classes are instances of Manager.
>>>>  3. assert that a attribute which is only in Manager is loaded.
>>>>
>>>> If this test case works it would be very nice.
>>>>
>>>
>>> yep, this is the issue - OJB doesn't.
>>> If you iterate and print the class types of the query result against 
>>> Employee then you only get Employee types.
>>>
>>> Think this is a "bug" in consistence of inheritance behavior in OJB, 
>>> because the other "inheritance mapping strategies" work different 
>>> and will return the real classes not only base class instances.
>>>
>>> I will add a test to reproduce your problem.
>>>
>>> regards,
>>> Armin
>>>
>>>> Best regards....
>>>>
>>>> carsten
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message