Ivo Friedberg
2010-02-22 13:21:09 UTC
We recently tested the actual implementation of ManyToMany relations,
revealing several problems:
Our tries with the actual implementation of ManyToMany relations using
autoStore resulted
in a SQLIntegrityConstraintException when trying to persist an Author,
related to two Books.
The author knows the Books, but the Books do not know the author. AutoStore
is enabled.
When looking at the sorted (by molder priority) Collection, the Author is
the first being persisted.
The create method of the ClassMolder, then calls a create method of all
FieldMolders,
but, in case of the ManyRelationResolver, they only return some
IdentityList,
and in my oppinion do not persist anything like the documentation would make
us believe.
After that, the Author object gets persisted, and till now everything looks
fine, but then the postCreate method,
of all FieldMolders get called. In the case of the
ManyToManyRelationResolver, this method tries to create all needed
entries in the ManyTable, to persist the relation between the objects.
The Method tries to check, that the related object is already persisted, but
therefor it calls the
isPersistent(...) method of the TransactionContext, only checking that the
object isTracking() and !isDeleted().
In this case that obviously isn't enough, cause the Books already are being
tracked due to calls of markCreate, but are not yet persisted,
causing an SQL foreign key violation!
I think analysing the problem, we have two points of failure. The first one
is the isPersistent method of the TransactionContext
which does not check enough cases.
The second one is the molder priority putting the Author first. This would
not be a problem if in the object related view the books would also
know about the author, cause then the entries in the many table, could be
created after persisting the books as well, but in our case it is
neccessary to create the books first, cause the author is the only object
which has the related object in it's context.
So in my oppinion both points of failure have to get cleaned before getting
it to work!
I also believe this is the same problem occured previously checking the
functionality of OneToMany Relations.
The tests we are running can be found in the StudentsProgram branch of
castor: castor/branches/castor-ase-09
package cascading-it/org/castor/cascading/many-to-many.
cheers Ivo
revealing several problems:
Our tries with the actual implementation of ManyToMany relations using
autoStore resulted
in a SQLIntegrityConstraintException when trying to persist an Author,
related to two Books.
The author knows the Books, but the Books do not know the author. AutoStore
is enabled.
When looking at the sorted (by molder priority) Collection, the Author is
the first being persisted.
The create method of the ClassMolder, then calls a create method of all
FieldMolders,
but, in case of the ManyRelationResolver, they only return some
IdentityList,
and in my oppinion do not persist anything like the documentation would make
us believe.
After that, the Author object gets persisted, and till now everything looks
fine, but then the postCreate method,
of all FieldMolders get called. In the case of the
ManyToManyRelationResolver, this method tries to create all needed
entries in the ManyTable, to persist the relation between the objects.
The Method tries to check, that the related object is already persisted, but
therefor it calls the
isPersistent(...) method of the TransactionContext, only checking that the
object isTracking() and !isDeleted().
In this case that obviously isn't enough, cause the Books already are being
tracked due to calls of markCreate, but are not yet persisted,
causing an SQL foreign key violation!
I think analysing the problem, we have two points of failure. The first one
is the isPersistent method of the TransactionContext
which does not check enough cases.
The second one is the molder priority putting the Author first. This would
not be a problem if in the object related view the books would also
know about the author, cause then the entries in the many table, could be
created after persisting the books as well, but in our case it is
neccessary to create the books first, cause the author is the only object
which has the related object in it's context.
So in my oppinion both points of failure have to get cleaned before getting
it to work!
I also believe this is the same problem occured previously checking the
functionality of OneToMany Relations.
The tests we are running can be found in the StudentsProgram branch of
castor: castor/branches/castor-ase-09
package cascading-it/org/castor/cascading/many-to-many.
cheers Ivo