please replace the method addJoin in SqlQueryStatement with the following:
private void addJoin(TableAlias left, Object[] leftKeys, TableAlias right, Object[] rightKeys, boolean outer, String name)
{
TableAlias extAlias, rightCopy;
left.addJoin(new Join(left, leftKeys, right, rightKeys, outer, name));
// build join between left and extents of right
if (right.hasExtents())
{
for (int i = 0; i < right.extents.size(); i++)
{
extAlias = (TableAlias) right.extents.get(i);
FieldDescriptor[] extKeys = getExtentFieldDescriptors(extAlias, (FieldDescriptor[])rightKeys);
left.addJoin(new Join(left, leftKeys, extAlias, extKeys, true, name));
}
}
// we need to copy the alias on the right for each extent on the left
if (left.hasExtents())
{
for (int i = 0; i < left.extents.size(); i++)
{
extAlias = (TableAlias) left.extents.get(i);
FieldDescriptor[] extKeys = getExtentFieldDescriptors(extAlias, (FieldDescriptor[])leftKeys);
rightCopy = right.copy("C" + i);
// copies are treated like normal extents
right.extents.add(rightCopy);
right.extents.addAll(rightCopy.extents); addJoin(extAlias, extKeys, rightCopy ,rightKeys, true ,name);
}
}
}/**
* Get the FieldDescriptors of the extent based on the FieldDescriptors of the parent
* @param extAlias
* @param fds
* @return
*/
private FieldDescriptor[] getExtentFieldDescriptors(TableAlias extAlias, FieldDescriptor[] fds)
{
FieldDescriptor[] result = new FieldDescriptor[fds.length];
for (int i = 0; i < fds.length; i++)
{
result[i] = extAlias.cld.getFieldDescriptorByName(fds[i].getAttributeName());
}
return result;
}getExtentFieldDescriptors is new and tries to get the correct fieldDescriptors please report any problems asap.
hth jakob
Peter Wieland wrote:
Hi Jakob,
Thanks for your answer. I'm afraid noone can pay enough to the ojb-crew to post the following question. I go for it anyways :-)
Wally wrote in his reply to my question that he thinks the problem is fixed in the latest CVS (I'm still using RC4 - did not change because our apps just entered a quite stable state and never change a running system...). So I have two questions: first, can anyone confirm that the bug is fixed in latest CVS? And the second question is (I hope I'm not going to be excluded from the list for this): should I upgrade to the latest CVS or should I wait for the 1.0 final release. In other words, could we have any estimaton of the release date (the website says two weeks since about aehm 2 months I think).
Regards,
Peter
hi peter,
how much did you pay to the ojb-crew to get an answer within two days ;)
anyway, the correct sql would look like this :
SELECT DISTINCT A0.gar* FROM Garage A0 LEFT OUTER JOIN Address A1 ON A0.garAddressOID=A1.addOID LEFT OUTER JOIN PersonAddress A1E0 ON A0.garAddressOID=A1E0.padOID ...
so imo this is a bug :(
jakob
Peter Wieland wrote:
Hi,
I posted the message below two days ago, and from my experience I would say if there is no reply within two days, there's very few chance to have an answer at all, that's way I annoy you one more time with this message.
This is quite important for us, so I would truly appreciate if someone from the OJB staff (or any other who knows how it works) could give me some hints.
I'd like to know if the problem I describe below is a known problem (or a known fact, perhaps you do not consider it a problem?) and if anyone has any suggestions how to proceed in the given case.
Thank you once again,
Peter
--- HIER BEGINNT DIE WEITERGELEITETE NACHRICHT ------------------------------ Von: [EMAIL PROTECTED] (Peter Wieland) Datum: 16.02.2004, 17:29:33 Betreff: Problem with inheritance mapping
Hi everyone,
I have two entity classes AddressImpl and PersonAddressImpl, PersonAddressImpl extending AddressImpl (below the interesting parts of my Mapping). A third class - GaragaeImpl - holds a reference to an AddressImpl (might be an AddressImpl or a PersonAddressImpl).
<class-descriptor class="de.armax.ce.manager.entity.AddressImpl" table="Address"> <extent-class class-ref="de.armax.ce.manager.entity.PersonAddressImpl"/> <field-descriptor autoincrement="true" primarykey="true" column="addOID" jdbc-type="VARCHAR" name="oID"/> ... </class-descriptor>
<class-descriptor class="de.armax.ce.manager.entity.PersonAddressImpl" table="PersonAddress"> <field-descriptor autoincrement="true" primarykey="true" column="padOID" jdbc-type="VARCHAR" name="oID"/> ... </class-descriptor>
<class-descriptor class="de.armax.ce.manager.entity.GarageImpl" table="Garage"> ... <field-descriptor column="garAddressOID" jdbc-type="VARCHAR" name="addressOID"/> <reference-descriptor proxy="true" auto-delete="false" auto-retrieve="true" auto-update="false" class-ref="de.armax.ce.manager.entity.AddressImpl" name="address"> <foreignkey field-ref="addressOID"/> </reference-descriptor> ... </class-descriptor>
As you can see, the primery key column has not the same name for the two tables (whereas the field name is the same for both classes). That's the source of my problem. I try to do a query by criteria with something like
Criteria crit = new Criteria(); crit.addEqualTo("address.aAddressField", aValue); Collection result = broker.getCollectionByQuery(QueryFactory.newQuery(GarageImpl.class, crit));
The generated SQL looks like
SELECT DISTINCT A0.gar* FROM Garage A0 LEFT OUTER JOIN Address A1 ON A0.garAddressOID=A1.addOID LEFT OUTER JOIN PersonAddress A1E0 ON A0.garAddressOID=A1E0.addOID ...
It seems that OJB is not aware of the different column names for the foreign keys of PersonAddressImpl and AddressImpl entities (the problem only occurrs for primary key columns, other columns are correctly mapped).
I would like to know if this is correct behaviour or not, in other words does OJB allow the user to use different foreign key column names in one extent or not. I would equally be interested in any suggestions how to get my code running if possible without renaming the foreign key column of PersonAddressImpl (this would break our global naming and design conventions).
Thanks for any help,
Peter
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--- ENDE DER WEITERGELEITETEN NACHRICHT--------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
