From graffito-dev-return-472-apmail-incubator-graffito-dev-archive=www.apache.org@incubator.apache.org Sun Aug 28 21:17:39 2005 Return-Path: Delivered-To: apmail-incubator-graffito-dev-archive@www.apache.org Received: (qmail 77012 invoked from network); 28 Aug 2005 21:17:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Aug 2005 21:17:39 -0000 Received: (qmail 63738 invoked by uid 500); 28 Aug 2005 21:17:38 -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 63715 invoked by uid 99); 28 Aug 2005 21:17:38 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Aug 2005 14:17:38 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of sandro.boehme@gmx.de designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Sun, 28 Aug 2005 14:17:54 -0700 Received: (qmail invoked by alias); 28 Aug 2005 21:17:35 -0000 Received: from p54A3D0A9.dip.t-dialin.net (EHLO [192.168.2.2]) [84.163.208.169] by mail.gmx.net (mp003) with SMTP; 28 Aug 2005 23:17:35 +0200 X-Authenticated: #1646957 Message-ID: <43122AEB.7070209@gmx.de> Date: Sun, 28 Aug 2005 23:21:47 +0200 From: =?ISO-8859-1?Q?Sandro_B=F6hme?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: graffito-dev@incubator.apache.org Subject: Re: [jira] Created: (GRFT-37) Final JCR Mapping Document PROPOSAL // mapping structure References: <1604659921.1125061238085.JavaMail.jira@ajax.apache.org> <43108692.9020205@gmx.de> <431092A7.7090508@gmx.de> <3b728ee905082810118b6a183@mail.gmail.com> <43121F36.2020401@gmx.de> In-Reply-To: <43121F36.2020401@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Sandro B�hme wrote: > explained in the proposal doc, we need to map simple fieds, bean > >> fields and collection. So, we need to use different tags for that. >> >> > Where do you see the difference between field and a bean-field? > There are 4 "types" for attributes/fields : * Simple fields : primitive data types and simple objects (String, Long, Double, ...) * Bean fields : One class can contain an 1..1 association to another bean. In this case, the attribute is a custom object. * Collection fields : One class can contain an 1..n association to a collection of beans (or Map). The m..n association will be also supported. * Reference field : One good example to understand the "reference" type is the Folder concept. A folder "B" can have an attribute called "parentFolder" which is a simple field pointing to the parent folder "A" . Of course, in a JCR repository, it is a nonsense for persist this "parentFolder" attribute into a "B" subnode. We could add a "type" attribute to the field-descriptor or the sub-tag () of it. It can contain not only primitive types but also custom java classes that have a mapping defined in the mapping file. This already works in my prototype (The "Folder" has a "Document"). With the interface of the AtomicTypeConverter the user should be able to define a custom mapping for java classes that use bean property types not supported by the JCR. I used it to define a custom (build in) mapping for java.util.Date because the JCR only knows "Calendar". This way the custom java classes can reuse the date type as their bean types and the custom converter knows how to convert the data. The converters are registered in the factory. As soon as the object to item component or the item to object component hit a registered class which is to be persisted it will use the registered custom converter to do the real conversion. That's the java.util.Date example: private AtomicTypeConverter utilDateTypeConverter = new AtomicTypeConverter(){ public String getPropertyType(){ return PropertyType.TYPENAME_DATE; } public Value getJcrValueFromJavaObject(Object propValue){ if (propValue==null) return null; Calendar calendar = Calendar.getInstance(); calendar.setTime((java.util.Date)propValue); return this.getValueFactory().createValue(calendar); } public Object getJavaObjectFromJcr(Node node, String jcrPropName) throws ValueFormatException, PathNotFoundException, RepositoryException{ Calendar calendar = node.getProperty(jcrPropName).getDate(); Date date = calendar.getTime(); return date; } public Class[] getJavaTypes() { Class[] javaTypes ={java.util.Date.class}; return javaTypes; } }; Regards, Sandro