Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 49469 invoked from network); 9 Aug 2010 20:41:21 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 9 Aug 2010 20:41:21 -0000 Received: (qmail 7984 invoked by uid 500); 9 Aug 2010 20:41:21 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 7918 invoked by uid 500); 9 Aug 2010 20:41:20 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 7909 invoked by uid 99); 9 Aug 2010 20:41:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Aug 2010 20:41:20 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of chadmichaeldavis@gmail.com designates 209.85.161.42 as permitted sender) Received: from [209.85.161.42] (HELO mail-fx0-f42.google.com) (209.85.161.42) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Aug 2010 20:41:12 +0000 Received: by fxm14 with SMTP id 14so371365fxm.1 for ; Mon, 09 Aug 2010 13:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=2j4WDYinJLl6UQGb1dcZIRhkFlGJ2Gf/FPW3mmFq76c=; b=M+cRGusVP8Gv9PlOUHKxHD6v/VPe4AFL8/jtyhtruBfPb6+pHur6QHRBNR04m9N49G str5xVC0gWw7+e/2kkX93JNnKZefBYX0pqM0Jrr+JFjFr9J8NU0ZIXbgfZqUaphvgxLW Rb2WTAuoUpJOeb0ucF+aShs1W3FjwbOG/90/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Pyt9oOvd6mal/7TTaNa1dNJ2ceGymjaefTcroywfFUJGBo3c8QwJpYNVB+1AHQ0Y4r KLFlcOrrWjbVDPeHVHFG8zJpUEF61YbvLtlmich7oXtAxSqRHcjSRh6jEvgvKv3J2Whc iLEH1N7vZn5GImpcd4iGmFp+U/rWuOaojByHw= MIME-Version: 1.0 Received: by 10.239.133.196 with SMTP id 4mr815079hbw.187.1281386452267; Mon, 09 Aug 2010 13:40:52 -0700 (PDT) Received: by 10.239.149.138 with HTTP; Mon, 9 Aug 2010 13:40:52 -0700 (PDT) Date: Mon, 9 Aug 2010 14:40:52 -0600 Message-ID: Subject: reference properties across workspaces From: ChadDavis To: users@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org I'm facing a design choice that I don't feel very qualified to make. Perhaps it's not so important, but I don't want to overlook any easily avoided consequences. I'm building a simple content management system. I have documents in folders, etc. I'm using a second workspace for a "publish" workspace; when users want certain content to go live, they publish them. They are then cloned to the publish workspace. Folders are handled similarly. Until recently, I hadn't thought of moving any other data to the publish workspace, other than the documents that are published, and the folders that hold them. However, my folders have REFERENCE typed properties that point to configuration type data. I'm hesitant to move this data to the publish since it doesn't seem related to the publish use case. But if I have a reference property with a value, when I clone the folder the reference will be invalid. So . . . any suggestions? Is it common to have to clone over the entire depenency of referenced nodes?