Browse Prior Art Database

Method for Providing Soft-Delete with the Java Content Repository that Maintains Referential Integrity Disclosure Number: IPCOM000131170D
Original Publication Date: 2005-Nov-09
Included in the Prior Art Database: 2005-Nov-09
Document File: 4 page(s) / 42K

Publishing Venue



Disclosed in this article is a method to provide soft-delete that maintains referential integrity using the Java Content Repository (JCR) specification ( This method allows JCR content to be soft-deleted if inbound references keep the content from being deleted without reserving the old node namespace or disrupting the referential integrity of inbound references. It also details the method for efficient cleanup of soft-deleted data.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 4

Method for Providing Soft-Delete with the Java Content Repository that Maintains Referential Integrity

     The Java Content Repository (JCR) specification ( defines data representations that are independent of their underlying repository implementation. It provides persistence semantics and a caching mechanism to allow for efficient repository operations. It also introduces a concept of references to other data in the repository. References ensure referential integrity and restricts data that is being referenced from being deleted. However, this referential integrity sometimes makes removing data difficult or impossible. In order to delete a piece of data, all references to that piece of data must be removed. However, given access control constraints, you might not have the required permissions to remove references from all the pieces of data referencing the data to be deleted. In addition, usually when deleting data, the desired operation is to delete the data and not modify all references to the data. If the application is trying to maintain strict audit history and control, this is an undesirable side effect. In order to solve this problem, we created a method to allow for soft deleting of data that maintains referential integrity and maintains the correct audit history for the operation.

     In order to maintain the referential integrity of the references, the piece of data cannot be removed. However, the path and name cannot stay the same or else the namespace will be reserved for the deleted node. The first part of the solution is to add a new child node definition to the repository types that will be able to support soft delete. The child node definition allows any type, defines a name, and allows multiple nodes with the same name. The name of the child node definition can be any name, but it is recommended that the name not reserve any commonly used namespace. An example child node definition name could be ".deleted". Throughout this article, we will refer to this child node definition as the deleted bucket.

     The second part of the solution is to move the node into the deleted bucket instead of calling node.remove() on its parent. By moving the node into the deleted bucket, the name of the node has changed, which allows a new node with the original name to be created. However, the JCR UUID of the node does not change when a node is moved, and since all references are done based on the UUID of the node, no referential integrity is violated. All nodes referencing the soft deleted node will still be able to access the node and change it if desired, but will also be aware that the node has been soft deleted by analyzing the new name of the no...