Hi Armin,
> The method CollectionTypes#getCollectionClass is correctly
implemented.
> First this method checks for user specific collection class
> implementations (implementations of ManageableCollection), then this
> method try to resolve the collection class implementations for 1:n and
> m:n collection-fields (of type Collection, List, Set or array types)
of
> persistence capable classes.
>
> The "real bug" is a typo in the OJB.properties file:
> replace
>
CollectionTypes.OneToManySet=org.apache.ojb.broker.util.collections.Man
> ageableSet
> with
>
CollectionTypes.OneToManySet=org.apache.ojb.broker.util.collections.Man
> ageableHashSet
>
> I will fix this ASAP. Thanks again.
I'm sorry, but the change in the OJB.properties file didn't solve the
problem.
I still get the MetadataException "Cannot determine a collection type
for collection/list/set/array field 'devices' of type 'class
java.util.HashSet' in persistence capable class 'Abc'"
As I wrote: HashSet.class.isAssignableFrom(java.util.Set.class) will
ALWAYS fail.
Please remember, the method can only be successful in the direction
superclass.isAssignableFrom(subclass).
The only superclass of java.util.Set is java.util.Collection.
So as long as there is a HashSet instead of a Set used as field the
check fails, despite the OJB.properties file.
In 1.0.4 this assignable check was against RemovalAwareSet, which is a
subclass of HashSet.
> > Another bug is in the statement creation when a subclass is
involved.
> > Note: A0 is the subclass table from A1, PHB_USRID exists only in A1
> >
> > 1.0.4 creates something like
> >
> > SELECT
> > A0.PHB_ID ,
> > A1.PHB_USRID ,
> > FROM
> > IPT_PHONEBOOKCSV A0
> > INNER JOIN IPT_PHONEBOOK A1
> > ON
> > A0.PHB_ID = A1.PHB_ID
> > WHERE
> > PHB_USRID IS NULL
> >
> >
> >
> > 1.0.5rc1 creates
> >
> > SELECT
> > A0.PHB_ID ,
> > A1.PHB_ID ,
> > A1.PHB_USRID ,
> > FROM
> > IPT_PHONEBOOKCSV A0
> > INNER JOIN IPT_PHONEBOOK A1
> > ON
> > A0.PHB_ID = A1.PHB_ID
> > WHERE
> > A0.PHB_USRID IS NULL
> >
> >
> > The WHERE criteria assignment to A0 the statement produces an
> exception
> > for the nonexisting column A0.PHB_USRID.
> >
> > Note, that in the SELECT of 1.0.5rc1 is also A1.PHB_ID, which is not
> in
> > the statement of 1.0.4.
>
> If PHB_USRID only exists in A1 then A1 is a subclass of (super) class
> A0. In this case it's not allowed to build a query with target class
A0
> and fields only existing in A1.
> Is this the case? If not, please post some more details (java pseudo
> code, class mapping).
class A1
{
PHB_ID;
PHB_USRID;
PHB_NAME;
}
class A0 extends A1
{
PHB_CSV;
}
And the tables are
Table A1
PHB_ID
PHB_USRID
PHB_NAME
Table A0
PHB_ID
PHB_CSV
Because of the inheritance there shouldn't be a need for the column
PHB_USRID in the table for the derived class A0.
The correct statement should be
SELECT
A0.PHB_ID ,
A0.PHB_CSV ,
A1.PHB_USRID,
A1.PHB_NAME
FROM
A0 INNER JOIN A1 ON A0.PHB_ID = A1.PHB_ID
WHERE
A1.PHB_USRID IS NULL
I'm not sure if the 1.0.4 resolved this correct but it didn't add the
alias to the where clause so the database assigned the correct column by
itself.
Regards,
Sascha Broich
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
