On Nov 20, 2007, at 3:55 AM, Andrea Bollini wrote: > Larry Stone ha scritto: >>> Collection * - * Item >>> >> >> It's worth noting that while an Item may be a member of multiple >> Collections, it still refers to only one of them as its "owner"; >> it is >> returned by getOwningCollection(). > true but IMHO this is not really needed...
Well, what I've suggested in my previous email is not wether it is needed or not, but where it should correctly reside in relational terms, "owner" is a relationship, not an attribute of Item and Collection, thus the more appropriate location would be in the container or relationship tables. I.E. rather than: > ------------------------------------------------------- > -- Item table > ------------------------------------------------------- > CREATE TABLE Item > ( > item_id INTEGER PRIMARY KEY, > submitter_id INTEGER REFERENCES EPerson(eperson_id), > in_archive BOOL, > withdrawn BOOL, > last_modified TIMESTAMP WITH TIME ZONE, > owning_collection INTEGER > ); > ------------------------------------------------------- > -- Collection2Item table > ------------------------------------------------------- > CREATE TABLE Collection2Item > ( > id INTEGER PRIMARY KEY, > collection_id INTEGER REFERENCES Collection(collection_id), > item_id INTEGER REFERENCES Item(item_id), > ); instead have > ------------------------------------------------------- > -- Item table > ------------------------------------------------------- > CREATE TABLE Item > ( > item_id INTEGER PRIMARY KEY, > submitter_id INTEGER REFERENCES EPerson(eperson_id), > in_archive BOOL, > withdrawn BOOL, > last_modified TIMESTAMP WITH TIME ZONE > ); > ------------------------------------------------------- > -- Collection2Item table > ------------------------------------------------------- > CREATE TABLE Collection2Item > ( > id INTEGER PRIMARY KEY, > collection_id INTEGER REFERENCES Collection(collection_id), > item_id INTEGER REFERENCES Item(item_id), > owning_collection BOOL > ); Ownership is a relationship and not a attribute and the dependency is one way. This also is an example that enforces third normal form because you cannot have a owning collection for which the item is not a member. (Although you can have multiple owners). >> When an Item is accessed directly, >> by itself without the navigational context of one of the >> Collections it belongs to, it consults the owning Collection for >> display style > this is only one possibility and it is not the most useful (see > MedataStyleSelection in 1.5) Very true and we will see that Manakin will mix this up even more. >> and policies (e.g. access control by Collection admins). >> > the auth system need a lot of work, in my path "community admin" that > introduce some hierarchy control I have used the owning collection as > the only real parent i.e. if I want modify the item but I have not > direct permission I check for ADMIN right on owning collection... > this is not optimal, if we have an item mapped in an other > collection I > think that only directly authorized people or ADMIN of both collection > should manage it > For Daniele works I recommend to keep ownCollection in place but I > think > that we need to remove it in future version. > > PS:the concept of owning collection is used also in workflow and > submission system but there is a main difference: the data are > stored in > inProgressSubmission object not in the item object. Also in this > case I > hope that we can introduce a more modular way to select workflow > process > and submission process then simply use the "owning collection". > Andrea Andrea, that is another example of what I speak of above. At least in this case, we see that inProgressSubmission (or WorkspaceItem) is really a "container" like collection and we've attached the item to that rather than attaching it to the item. I just think this is much cleaner and actually does not require altering the item table to move an item between WorkspaceItem and WorkflowItem when it is moved from Submission to Management Workflows. I would support moving/or removing owning_collection if it improved the model and the ability to work with tools. I think we would want a path of deprecation however, and using the above "relationship" approach could more easily give us that. -Mark ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
