Bug 118416

Created attachment 98613 [details]
current failing patch

Apply this patch and observe IsolatedTest fail, when called like so:

$ ant -Djunit.suite=CategorizationSuite.class \
  -Djunit.test=IsolatedTest.class runtests

(Cc'ing Archit.)

I can't get this thing to work.  I changed Category.pdl like so:

|object type UseContext {
|    BigDecimal[1..1] id = cat_root_cat_object_map.id;
|
|    String[0..1] useContext = cat_root_cat_object_map.use_context;
|
|    unique (categoryOwner, useContext);
|    object key (id);
|}
|
|association {
|    UseContext[0..1] ownerUseContext = join cat_categories.category_id
|                                         to cat_root_cat_object_map.category_id;
|
|    Category[1..1] rootCategory = join cat_root_cat_object_map.category_id
|                                    to cat_categories.category_id;
|}
|
|association {
|    UseContext[0..1] rootUseContext = join acs_objects.object_id
|                                        to cat_root_cat_object_map.object_id;
|
|    ACSObject[1..1] categoryOwner = join cat_root_cat_object_map.object_id
|                                      to acs_objects.object_id;
|}

As far as I can tell, this shouldn't require any changes to
Category.java.  From the "UseContext" perspective, the logical model
hasn't changed.  (From the "ACSObject" or "Category" perspective, it
has.  These objects have acquired the attributes "rootUseContext" and
"ownerUseContext" respectively.)

The testGetRootCategories test in UseContextTest fails.

|$ p4 print //core-platform/dev/.../UseContextTest.java#4 | \
|  grep -v '//core' | cat -n - | head -n 86 | tail -n 8
|    79      public void testGetRootCategories() {
|    80          Map map = new HashMap(3);
|    81          Category.setRootForObject(group1, root1, CTX1);
|    82          map.put(CTX1, root1);
|    83          Category.setRootForObject(group1, root2, CTX2);
|    84          map.put(CTX2, root2);
|    85          Category.setRootForObject(group1, root3, CTX3);
|    86          map.put(CTX3, root3);


What happens is, the call to setRootForObject at line 81 generates an
insert into cat_root_cat_object_map.  A similar call to the same
method at line 83 generates no inserts.  Trying to force a flush by
calling save() results in the following error:

    Unable to send all events to database for object
      [com.arsdigita.categorization.UseContext:{id=25008}]
    because these required properties are null:
      [com.arsdigita.categorization.UseContext:{id=25007}].categoryOwner

The error makes no sense to me.  In this particular example, 25008 is
the id of the "UseContext" object created by call to setRootForObject
at line 83, whereas 25007 is the id of the "UseContext" object created
at line 81.  Watching the logs, I do see a successful insertion of the
25007 object into cat_root_cat_object_map.

Attachment 98613 [details] (see comment #1) contains a patch with the described
changes to Category.pdl and some instrumentation to help diagnose the
error.  You should be able the patch by fixing the paths in the three
places to reflect your particular p4 layout, and then running

$ patch -p0 < use-context.patch


P.S.
    Either I'm doing something really dumb, or it's a persistence edge
    case that we haven't seen before, due to the fact that we don't
    have a similar PDL model anywhere else in our code.  Note that in
    both association blocks, the multiplicities of both ends of the
    association are no greater than 1.  One end is 0..1 while the
    other is 1..1.  I could find only two other places in our code
    where a somewhat similar logical model is employed.

    In //core-platform/dev/pdl/com/arsdigita/web/Application.pdl,

        association {
            PackageInstance[0..1] packageInstance =
            Application[0..1] application =
        }

    In //cms/dev/pdl/com/arsdigita/content-section/Folder.pdl,

        association {
            ContentItem[0..1] index = 
            Folder[0..1] indexed = 
        }

    In all other cases, at least of the ends of the association has a
    multiplicity of 0..n.

Ok, Archit figured it out.  The multiplicities were wrong.  In both
cases, we should have
   UseContext[0..n]

instead of
   UseContext[0..n]

I'm going to ask Dennis to give me write permission on the trunk,
so I can commit this change.


(This is like the third or fourth time I forget to change 
multiplicities correctly when converting an object type to an
association block.)

I meant,
  "instead of UseContext[0..1]"