db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Wieland <peter.wiel...@gmx.de>
Subject Re: Unique key constraint violations with M-to-N Mapping (patch proposition)
Date Tue, 09 Mar 2004 09:23:41 GMT
Hi there,

I described a problem causing unique key constraint violations in m-to-n
indirection tables on the user list (see original post at the end of this
message). Axel already proposed a patch to fix this problem. I want to
propose another patch.

I think it is correct to only reload m-to-n implementors if the other end
was saved by autoupdate previously. Hence I propose to leave org.apache.ojb.
broker.core.PersistenceBrokerImpl.storeCollectionObject(Object obj, boolean
insert, CollectionDescriptor cds, Collection currentMtoNKeys, Object
otherObj) unchanged.

I think the problem occurs at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeCollections(Object
obj, List listCds, boolean insert), where the currentMtoNKeys are not loaded
if we are performing an insert. According to my post (see below), I think it
is not always allowed to do so.

Hence, 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.

Regards,

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


Mime
View raw message