jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Klein (JIRA)" <j...@apache.org>
Subject [jira] Created: (JCR-840) Support for setting jcr:created when importing Into the repository
Date Wed, 11 Apr 2007 14:24:33 GMT
Support  for setting jcr:created when importing Into the repository

                 Key: JCR-840
                 URL: https://issues.apache.org/jira/browse/JCR-840
             Project: Jackrabbit
          Issue Type: Improvement
          Components: JCR 1.0.1, JCR 2.0
    Affects Versions: 1.2.3, 1.4, 2.0
         Environment: Java 1.6_01, Tomcat 5.5.x, Postgresql 8.2
            Reporter: Julian Klein
            Priority: Minor

When importing content from one repository or source into Jackrabbit, it is impossible to
set the jcr:created property.  The specification indicates that the property is protected,
however section 7.3 indicates that "Level 2 Repositories must support the import of content".
 It goes on to read in section 7.3.3,

"When an element or attribute representing such a property is encountered, an implementation
may either skip it or respect it.  To respect it means to import it and alter the internal
state of the repository in accordance with the semantics of the property in the given implementation.
.... To skip the element or attribute means not to import it all.  It does not mean to import
it but then ignore its semantic implications.

The implementation-specific policy regarding what to skip and what to respect must be internally
consistent. For example, it makes no sense to skip jcr:mixinTypes (thus missing the presence
of mix:lockable, for example) and yet respect jcr:lockOwner and jcr:lockIsDeep."

Overall, the ability to set the value of jcr:created when importing content will allow conversion
from other repositories (e.g Apache Slide) to Jackrabbit as well as allowing a complete export
of the jackrabbit repository to be restored to its proper state at a later point in time.
 Setting the value could be done during the execution of the importXML and getImportContentHandler
methods available to the Session and the Workspace objects.  By supporting this one could
transition to jackrabbit and the dates of creation from the original repository (e.g. again
Slide) would reflect the origins of the repository rather than the date when the transition
occurred.  Finally, this is not to be confuse with the various restore methods in the JCR
API which allow for restoring a node or workspace to a previous state (versioning).

see the mailing lists discussion that spawned this issue:

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message