From graffito-dev-return-979-apmail-incubator-graffito-dev-archive=www.apache.org@incubator.apache.org Wed Feb 08 11:55:34 2006 Return-Path: Delivered-To: apmail-incubator-graffito-dev-archive@www.apache.org Received: (qmail 5413 invoked from network); 8 Feb 2006 11:55:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 8 Feb 2006 11:55:32 -0000 Received: (qmail 58728 invoked by uid 500); 8 Feb 2006 11:55:30 -0000 Mailing-List: contact graffito-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: graffito-dev@incubator.apache.org Delivered-To: mailing list graffito-dev@incubator.apache.org Received: (qmail 58716 invoked by uid 99); 8 Feb 2006 11:55:30 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Feb 2006 03:55:30 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of christophe.lombart@gmail.com designates 66.249.92.200 as permitted sender) Received: from [66.249.92.200] (HELO uproxy.gmail.com) (66.249.92.200) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Feb 2006 03:55:29 -0800 Received: by uproxy.gmail.com with SMTP id m2so448057uge for ; Wed, 08 Feb 2006 03:55:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ArKI788OCoNABJx13ibrnkNIXtx/yA+0EvUKo5mClQIO8vOoufpJoybdiMomYizK5G6Pn68cd+Ft9TmCiigPGhfEH01+IT0PalzmWi+QihMj6IzsXMVsw+/aea8so9HuTr6KEGd/wRP5jsM/31G50hBSLf7Lpo6LKmnc9qYepP8= Received: by 10.48.235.15 with SMTP id i15mr1951932nfh; Wed, 08 Feb 2006 03:55:08 -0800 (PST) Received: by 10.48.255.8 with HTTP; Wed, 8 Feb 2006 03:55:08 -0800 (PST) Message-ID: <3b728ee90602080355v13553cd8x4bcc5758064e8523@mail.gmail.com> Date: Wed, 8 Feb 2006 12:55:08 +0100 From: Christophe Lombart To: graffito-dev@incubator.apache.org Subject: Re: mapping descriptor revisited In-Reply-To: <43E9D39C.4030508@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43E660DE.3050909@gmail.com> <43E9D39C.4030508@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Cool ! On 2/8/06, Alexandru Popescu wrote: > Hi! > > All the features considered in this mail were implemented, (tested) and a= re in the SVN head. > > Later this week, I will look into collection-descriptors and interface/in= heritance. For the moment, > I cannot promise anything, but I really hope to find a couple of hours t= o do it. > > cheers, > > ./alex > -- > .w( the_mindstorm )p. > > #: Alexandru Popescu changed the world a bit at a time by saying (astral = date: 2/5/2006 10:32 PM) :# > > Hi! > > > > I finally had the time to revisit the mapping descriptor for class-desc= riptor, field-descriptor and > > bean-descriptor. So far here are my conclusions: > > > > A] class-descriptor > > > > i/ jcrSuperTypes: doesn't seem to make sense to be used, cause we are n= ot gonna create custom node > > definitions. These are already defined within the repository and the in= formation is contained in the > > description of the jcrNodeType. > > > > ii/ there is no way to declare that the node to be created has mixins. = I would like to add a > > jcrMixinTypes that specifies a comma separated list of mixins for the n= ode to be created. > > > > Adding mixins to a node at runtime is an allowed operation and I have g= ood examples where this would > > make sense. > > > > iii/ there is no way to declare a custom converter. Currently a class-d= escriptor is > > persisted/fetched by the ObjectConverterImpl. But considering the follo= wing suggestions (see > > bean-descriptor) it would make sense to allow specifying a custom conve= rter. > > > > iv/ Currently there is not possible to provide multiple mappings for th= e same class. This may sound > > weird in the first place, but I think there are scenarios where this wo= uld make sense. However, I > > don't consider this a high priority. > > > > B] field-descriptor > > > > The following attributes used inside the mapping: > > > > jcrAutoCreated (true | false) "false" > > jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | AB= ORT) "COPY" > > jcrMandatory (true | false) "false" > > > > are duplicating the definition of a node type and cannot really be used= (they are just informal). I > > would suggest removing them. > > > > C] bean-descriptor > > > > The current bean-descriptor is able to handle only the scenario where t= he properties of the bean are > > persisted on a direct subnode of the current node. As I pointed in a se= parate thread and Christophe > > marked in the http://issues.apache.org/jira/browse/GRFT-54, the bean-de= scriptor should be able to > > handle at least 3 scenarios: > > > > a/ persisting the properties of the bean on the current node (a compone= nt bean) > > b/ persisting the properties of the bean on a direct subnode of the cur= rent node (the current behavior) > > c/ persisting the properties of the bean on subtree structure of the cu= rrent node or an independent > > node in the repository (consider GRFT-54 for the first part and a refer= enceable node for the 2nd part). > > > > The modifications needed for this to work are quite simple: > > > > a/ add a inline attribute with true/false values: if set to true, the b= ean properties are created as > > properties of the current node > > > > b/ add a converter attribute with a fully qualified name of a converter= class, that will be > > responsible for persisting/fetching the node. The API for this converte= r is a reduced version of the > > current ObjectConverter interface. If not specified the converter to be= used is the > > ObjectConverterImpl (the current implementation). > > > > > > I would also like to remove the following attributes from the mapping. = They are duplicating a node > > type definition and cannot be directly used: > > > > jcrAutoCreated (true | false) "false" > > jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | AB= ORT) "COPY" > > jcrSameNameSiblings (true | false) "false" > > > > > > As pointed previously, there are a few more things we need to define: r= eview collection-descriptor, > > define behavior for interface/inheritance (for queries, and persistence= too). > > > > However, once agreeing on the above points will allow me to implement t= he changes right away. Than > > we can continue with the rest. > > > > I would like to start doing the above changes right away, so I am eager= to hear your opinions and > > comments as soon as possible. Than we will have a new face of the OCM := -). Thanks in advance, > > > > ./alex > > -- > > .w( the_mindstorm )p. > > > > > > -- Best regards, Christophe