Re: OpenEJB PK issue
Hi Gianny, I am not much familiar to the open-ejb/tranql codebase . But I plan to get a lot more familiar to it. I have put in a fix for the issue though I am not sure how appropriate it is as I am yet to get a complete picture of the working of openejb/tranQL. The JIRA issue is http://issues.apache.org/jira/browse/GERONIMO-1374. P.S. Can you please point me to where there is some documentation on TranQL/OpenEJB (Architecture etc). Thanks Manu
Re: OpenEJB PK issue
Hi Manu,
Once again, thanks for your debugging!
I had a look to the DD and I have identified why the itests showing this
specifc case are working for us and not for you: basically in our test,
we have a OTM relationship between a CMP with a simple PK on the
one-side and a CMP with a compound PK on the many-side. Your case is
slightly different: the CMP on the one-side has a compound PK and hence
another code path is used.
Basically, the problem that you are raising is exactly what I was trying
to describe in one of my previous email:
"
About createCMPFieldAccessors, the
relatedEntity.getPrimaryKeyFields().size() test must also be replaced
by an isCompoundPK test. However, it seems that we should add a special
processing to handle a CMP field mapped to a FK column referencing the
(single) PK column associated to a compound PK having a single field.
"
Hm; I realise that this was far to be understandable.
This special processing works as follow:
1. if the CMP field, CMPField, is mapped to a FK column;
2. if the PK column referenced by this FK column is associated to a
compound PK column;
3. if the compound PK uses more than one CMP field:
3.1 then the accessor of CMPField must be read-only. (this is what we
currently have)
4. otherwise:
4.1 the accessor of CMPField must be read-write.
This purpose of the " if (null !=
ejb.getAssociationEndDefiningFKAttribute(name)) {" block is to set the
CMR field at the same time than the CMP field when a CMP field is mapped
to a FK column. BTW, it seems that you are familiar with OpenEJB and
TranQL; so, do you want to work on a patch to fix this problem? FYI, we
have a large and very interesting piece of work ahead of us to support
the persistence part of the EJB3 specification :)
Thanks,
Gianny
Manu George wrote:
Hi Gianny,
I put in a dirty hack and got my app working. The
problem I was facing was in the
private LinkedHashMap createCMPFieldAccessors(SQLQueryBuilder
queryBuilder, LinkedHashMap cmrFieldAccessor) throws QueryException {
method in CMPContainerBuilder
Here there is a if (null !=
ejb.getAssociationEndDefiningFKAttribute(name)) {
check inside which the CMR foreign Key was set to a read only field
during deployment. In my app the CMR FK is a part of the primary key
also. So during ejbCreate it gives error saying that it is a readonly
field. I just added a check to not go into this loop if the FK is also
a part of the PK.
and the app seems to be working. Hope this gives you more info abt
the problem I am facing
Regards
Manu
OpenEJB PK issue
Hi Gianny,
I put in a dirty hack and got my app working. The problem I was facing
was in the
private LinkedHashMap createCMPFieldAccessors(SQLQueryBuilder
queryBuilder, LinkedHashMap cmrFieldAccessor) throws QueryException {
method in CMPContainerBuilder
Here there is a if (null != ejb.getAssociationEndDefiningFKAttribute(name)) {
check inside which the CMR foreign Key was set to a read only field
during deployment. In my app the CMR FK is a part of the primary key
also. So during ejbCreate it gives error saying that it is a readonly
field. I just added a check to not go into this loop if the FK is also
a part of the PK.
and the app seems to be working. Hope this gives you more info abt the problem I am facing
Regards
Manu
Re: OpenEJB PK issue
You are right! And thanks for reviewing my commits :) Indeed, buildFaultHandler is still creating the wrong type of IdentityDefiner. I thought that all dependencies on the various IdentityDefiner implementations were removed from OpenEJB thanks to the introduction of IdentityDefinerBuilder; obviously, two references have been forgotten :( About createCMPFieldAccessors, the relatedEntity.getPrimaryKeyFields().size() test must also be replaced by an isCompoundPK test. However, it seems that we should add a special processing to handle a CMP field mapped to a FK column referencing the (single) PK column associated to a compound PK having a single field. Thanks, Gianny Manu George wrote: Hi Gianny, Was just seeing the fix you made. 1 question on that. In CMPContainerBuilder there are 2 methods private FaultHandler buildFaultHandler(SQLQueryBuilder queryBuilder, EJB definingEJB, CMRField field, int slot, boolean prefetch) throws QueryException and private LinkedHashMap createCMPFieldAccessors(SQLQueryBuilder queryBuilder, LinkedHashMap cmrFieldAccessor) I feel that in both of these methods instead of comparing based on relatedEntity.getPrimaryKeyFields().size() we need to change to ejb.isCompoundPK(). Am I right? Thanks Manu
OpenEJB PK issue
Hi Gianny, Was just seeing the fix you made. 1 question on that. In CMPContainerBuilder there are 2 methods private FaultHandler buildFaultHandler(SQLQueryBuilder queryBuilder, EJB definingEJB, CMRField field, int slot, boolean prefetch) throws QueryException and private LinkedHashMap createCMPFieldAccessors(SQLQueryBuilder queryBuilder, LinkedHashMap cmrFieldAccessor) I feel that in both of these methods instead of comparing based on relatedEntity.getPrimaryKeyFields().size() we need to change to ejb.isCompoundPK(). Am I right? Thanks Manu
