Unique key constraint violations with M-to-N Mapping

[Peter Wieland <pe...@gmx.de>]

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: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: Unique key constraint violations with M-to-N Mapping

[Peter Wieland <pe...@gmx.de>]

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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org