From jackrabbit-dev-return-2294-apmail-incubator-jackrabbit-dev-archive=www.apache.org@incubator.apache.org Thu Jun 09 11:41:18 2005 Return-Path: Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org Received: (qmail 88273 invoked from network); 9 Jun 2005 11:41:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Jun 2005 11:41:18 -0000 Received: (qmail 38839 invoked by uid 500); 9 Jun 2005 11:41:17 -0000 Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jackrabbit-dev@incubator.apache.org Delivered-To: mailing list jackrabbit-dev@incubator.apache.org Received: (qmail 38816 invoked by uid 99); 9 Jun 2005 11:41:17 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from relay.gossinteractive.com (HELO relay.gossinteractive.com) (212.104.154.111) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 09 Jun 2005 04:41:14 -0700 Received: from delboy.lan.gossinteractive.com ([10.10.10.240]) by relay.gossinteractive.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Jun 2005 12:42:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Jackrabbit Wiki] Update of "PersistenceManagerFAQ" by edgarpoce Date: Thu, 9 Jun 2005 12:40:53 +0100 Message-ID: <8D07567F3496FA4797E37564D4B4DC0E84648B@delboy.lan.gossinteractive.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Jackrabbit Wiki] Update of "PersistenceManagerFAQ" by edgarpoce thread-index: AcVs5B7pH02eAlEuTCK+PdUeKFbQggAAC4Ww From: "Simon Gash" To: , "Stefan Guggisberg" X-OriginalArrivalTime: 09 Jun 2005 11:42:33.0277 (UTC) FILETIME=[53205ED0:01C56CE8] X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Ah I see what you mean it's a very good analogy. I guess I view JackRabbit differently. Not being at the beginning of the project (joining 6 months ago) I came to it from a different angle. Having worked with RDBMS for the last 15 years does make you a bit biased. I've always seen it as a much better data dictionary minus the storage bit. I think there will be an adoption problem if I ask my client's to drop their RDBMS vendor in favour of a relatively new storage and retrieval technology. Then there's the problem with all those dba's... ;) Simon -----Original Message----- From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]=20 Sent: 09 June 2005 12:12 To: jackrabbit-dev@incubator.apache.org Subject: Re: [Jackrabbit Wiki] Update of "PersistenceManagerFAQ" by edgarpoce On 6/9/05, Simon Gash wrote: > I don't think that's right either. It's the wrong way round, its up to > the developer to make sure the decision about what is 'best' as a type > of persistence manager. There is no way any of us could know already=20 > how to measure what is 'best' for any other developers particular situation. >=20 > Sorry to be so pedantic but flexibility of storage is a huge strength=20 > of the jackrabbit software (and of the JSR 170). Getting the developer > to make the right decision for their own particular problems is the=20 > trick bit. >=20 me too sorry to be so pedantic ;) the role of the PM in jackrabbit (at least as i originally designed it) is comparable to the role of that layer in a rdbms that reads and writes raw table/record data to/from the disk (e.g. tablespace files in oracle). you wouldn't expect oracle to store the raw table/record data in ORM instead of its tablespace files i guess.=20 btw, edgar's PM FAQ quite nicely explains the role of the PM in jackrabbit. cheers stefan > Simon >=20 > -----Original Message----- > From: Serge Huber [mailto:shuber2@jahia.com] > Sent: 09 June 2005 11:39 > To: jackrabbit-dev@incubator.apache.org > Subject: Re: [Jackrabbit Wiki] Update of "PersistenceManagerFAQ" by=20 > edgarpoce >=20 >=20 > If I may, I think just changing the phrasing to something like : >=20 > Persistence managers that store the item states in a complex schema=20 > are not the best option for most users. >=20 > Regards, > Serge Huber. >=20 > ps : my schema is not that complex :) And I will probably in later=20 > version adopt something similar to Edgar's JDBC schema (with one table > per property type). >=20 >=20 > Stefan Guggisberg wrote: >=20 > >hi edgar > >first of all thanks for this very informative and usefull FAQ. > >i only have one comment: > > > > > > > >>=3D=3D=3D What about ORM-backed PMs? =3D=3D=3D > >>Persistence managers that store the item states in a complex schema=20 > >>are not the right way to go. Keep it simple, e.g. the=20 > >>objectPersistenceManager stores the item states as a raw stream of > bytes. > >> > >> > >> > >i remember having said something like that in a previous thread. this > >is my very personal view and allthough i still think it is correct=20 > >i'd rather like to have it understood as a recommendation, not an=20 > >absolute statement. what do you think? > > > >thanks > >stefan > > > > > > >=20 >=20 > Come visit us at: >=20 > Internet World 2005. June 14 - 16, Earls Court, Stand # A60 >=20 > Government Computing Expo. June 21 & 22, Earls Court, Stand # 804 >=20 > SOCITM Annual Event. October 16 - 18 Brighton Hotel, Stand # 28 GOSS - > Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and 88th in the Deloitte Technology Fast 500 EMEA. >=20 > This email contains proprietary information, some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient you may not use, disclose, distribute, copy, print or rely on this email. >=20 >=20 >=20 > Email transmission cannot be guaranteed to be secure or error free, as information may be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. This email and any files attached to it have been checked with virus detection software before transmission. You should nonetheless carry out your own virus check before opening any attachment. GOSS Interactive Ltd accepts no liability for any loss or damage that may be caused by software viruses. >=20 >=20 >