Once again me,
I want to propose a patch for the proble described below.
As I tried to describe, the fact, that a object is newly created does not
imply that there are no entries in a m-to-n-indirection-table in the db.
Consequently I propose to replace the following code in
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeCollections(Object
obj, List listCds, boolean insert), which uses an empty list of m-to-n keys
for inserts:
// use empty list on insert (by Andy Malakov)
if (insert)
{
currentMtoNKeys = Collections.EMPTY_LIST;
}
else
{
currentMtoNKeys = mtoNBroker.getMtoNImplementor(cds, obj);
if (col.getClass().isArray())
{
mtoNBroker.deleteMtoNImplementor(cds, obj,
Arrays.asList((Object[])col), currentMtoNKeys);
}
else
{
mtoNBroker.deleteMtoNImplementor(cds, obj, (Collection)col,
currentMtoNKeys);
}
}
The proposed replacement looks like the following:
currentMtoNKeys = mtoNBroker.getMtoNImplementor(cds, obj);
if (col.getClass().isArray())
{
mtoNBroker.deleteMtoNImplementor(cds, obj,
Arrays.asList((Object[])col), currentMtoNKeys);
}
else
{
mtoNBroker.deleteMtoNImplementor(cds, obj, (Collection)col,
currentMtoNKeys);
}
This works fine for my problems. But as I do not know the OJB codebase very
well, I'm not sure at all what impacts this change would have. Maybe someone
of the OJB staff may have a look at this.
Thanx,
Peter
> Hi all,
> since I updated from rc4 to CVS HEAD (friday afternoon) I have problems
> using non decomposed M-to-N relations. In the following scenario, I get
> unique key constraint violations in the indirection table:
> Let's say, we have the following:
> Person(0..*)----(0..*)Project
> I create a new Person, then I assign some Projects to the newly created
> Person. Next, I save the changed Projects. At this moment, the entries in
> the inderection table are automatically created but the newly created
> Person
> does not yet exist in the DB. When I finally try to save the newly created
> Person, OJB recognizes that the new Person is not present in the database
> and consequently performs an insert rather than an update. So far so good.
> Now, OJB presumes that, as the Person is newly created in the database,
> there is no need to check whether the entries in the indirection table
> exist
> already or not. It tries to perform an insert but the rows have already
> been
> inserted when saving the changed projects. This is the moment when the
> unique key constraint violation occurs. Is this correct behaviour?
> All m-to-n-collection-descriptors look like the following
> <collection-descriptor
> proxy="true"
> collection-class="org.apache.ojb.broker.util.collections.ManageableVector"
> auto-delete="false" auto-retrieve="true"
> auto-update="false" element-class-ref="foo.bar.Person"
> indirection-table="PersonProject"
> name="projects"
> >
> <fk-pointing-to-this-class column="personOID"/>
> <fk-pointing-to-element-class column="projectOID"/>
> </collection-descriptor>
> The same code with the same mappings worked well with rc4.
> Any help would be very welcome.
> Thanx,
> Peter
> ---------------------------------------------------------------------
> 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]
