Bug 113504 - Category#setRootForObject removes any existing mappings for the category in other contexts
Summary: Category#setRootForObject removes any existing mappings for the category in o...
Alias: None
Product: Red Hat Web Application Framework
Classification: Retired
Component: other   
(Show other bugs)
Version: nightly
Hardware: All Linux
Target Milestone: ---
Assignee: Vadim Nasardinov
QA Contact: Jon Orris
Depends On:
Blocks: 106481
TreeView+ depends on / blocked
Reported: 2004-01-14 19:12 UTC by Daniel Berrange
Modified: 2007-04-18 17:01 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-27 21:43:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
take one (8.22 KB, patch)
2004-01-19 21:42 UTC, Vadim Nasardinov
no flags Details | Diff

Description Daniel Berrange 2004-01-14 19:12:01 UTC
Description of problem:
The root category object map is a tuple of the form

  (object, category, use context)

With the constraint that (object,use context) is unique. The
setRootCategory method enforces an additional constraint of (object,
category) being unique. This prevents us using the same category tree
for several different purposes. For example the 'Local Government
Services List' for APLAWS is primarily used as the root for the
'subject' use context of an object. There are, however, circumstances
when it is used in the 'navigation' use context at the same time.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. ACSObject obj = SiteNode.getRootSiteNode()
   Category root = ...create the root cat...
2. Category.setROotForObject(obj, root, 'navigation');
3. Category.setRootForObject(obj, root, 'subject');
Actual results:
Only the (obj, root, 'subject') triple is persisted.

Expected results:
Both the (obj, root, 'subject') and (obj, root, 'navigation') tuples
are persisted.

Additional info:

Comment 1 Vadim Nasardinov 2004-01-14 20:00:25 UTC
I recall spending a fair amount of time thinking through the
constraints that I ended up putting in, but for the life me I
can't remember the rationale for requiring that (obj, category)
be unique.

It seems like it would be sufficient to require that (obj, useContext)
be unique.

So, yes, it does look like an unnecessary constraint to me now.
If I come to remember why I put it in there in the first place,
I'll post.

Comment 2 Vadim Nasardinov 2004-01-16 23:05:52 UTC
Ok, I remember now.  Your description is a little backwards.  The
(object, category) uniqueness is the primary constraint (imposed by
the data model), while the (object,useContext) uniqueness constraint
is the additional one.  Not the other way around.

I agree, in principle, that the only constraint we should impose on
(object, category, useContext) tripes is that (object,useContext) be

The troublesome (object,category) uniqueness constraint is the result
of the chosen implementation.  The cat_root_cat_object_map table is
the result of the following PDL:

association {
    Category[0..n] rootCategory = ...
    ACSObject[0..n] categoryOwner = ...

    String[0..1] useContext = cat_root_cat_object_map.use_context;

The logical model looks correct to me.  I am not sure how I would go
about modeling this differently than the above.

The physical model is auto-generated by DDLWriter:



  create table cat_root_cat_object_map (
      category_id INTEGER not null,
          -- referential constraint for category_id deferred due to circular dependencies
      object_id INTEGER not null,
          -- referential constraint for object_id deferred due to circular dependencies
      use_context VARCHAR(4000),
      constraint cat_roo_cat_obj_map_ca_p_11spa
        primary key(object_id, category_id)

I'm not sure if persistence would get confused, if I were to remove
the primary key constraint manually.  Cc'ing Archit.

Comment 3 Vadim Nasardinov 2004-01-19 21:42:27 UTC
Created attachment 97107 [details]
take one


What do you think about turning the above association block into a
full-blown object type with a surrogate primary key?

Note to self:
Attached is my current minimal patch.  It doesn't seem to work --
probably because I'm doing something stupid.  I'm getting the
following exception:

2004-01-19 16:01:28,790 [ main] INFO  rdbms.RDBMSEngine - {:useContext10=null,
2004-01-19 16:01:28,792 [ main] ERROR rdbms.RDBMSEngine - select crcom.id as
       crcom.use_context as c_2
from cat_root_cat_object_map crcom
where (crcom.object_id = :categoryOwner9) and (crcom.use_context is null)
java.sql.SQLException: ERROR:  parser: parse error at or near ":" at character

	at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:142)



	at com.redhat.persistence.Cursor.execute(Cursor.java:124)
	at com.redhat.persistence.Cursor.next(Cursor.java:108)
	at com.arsdigita.persistence.DataQueryImpl.next(DataQueryImpl.java:465)


Character 117 is the ":" in :categoryOwner9 in the "where" clause.  I
think this should be a question mark instead.  Archit is in a meeting
right now that he isn't likely go get out of soon.  So, I'm putting
this thing on hold for now, and am going to take a look at 113447
(totally unrelated).

Comment 4 Daniel Berrange 2004-01-20 09:39:01 UTC
Yeah, that idea looks reasonable to me, particularly since we've not
got any legacy code to worry about.

Comment 5 Vadim Nasardinov 2004-01-20 22:54:35 UTC
Change 39552 seems to fix this.  (I still need to do some cleanup.)

Comment 6 Vadim Nasardinov 2004-01-21 16:40:06 UTC
Dan's change 39556 and my change 39567 seem to have tied up most
of the loose ends.  Marking QA_READY.

Comment 7 Vadim Nasardinov 2004-01-21 17:56:20 UTC
Dennis added an upgrade script for Oracle in change 39581.

Comment 8 Vadim Nasardinov 2004-01-21 18:44:49 UTC
Dennis added an upgrade script for PostgreSQL in change 39582.

Note You need to log in before you can comment on or make changes to this bug.