Return-Path: Delivered-To: apmail-cayenne-dev-archive@www.apache.org Received: (qmail 6412 invoked from network); 1 Jun 2010 16:32:52 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Jun 2010 16:32:52 -0000 Received: (qmail 76059 invoked by uid 500); 1 Jun 2010 16:32:52 -0000 Delivered-To: apmail-cayenne-dev-archive@cayenne.apache.org Received: (qmail 76023 invoked by uid 500); 1 Jun 2010 16:32:51 -0000 Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cayenne.apache.org Delivered-To: mailing list dev@cayenne.apache.org Received: (qmail 76015 invoked by uid 99); 1 Jun 2010 16:32:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jun 2010 16:32:51 +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 mkienenb@gmail.com designates 209.85.212.43 as permitted sender) Received: from [209.85.212.43] (HELO mail-vw0-f43.google.com) (209.85.212.43) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jun 2010 16:32:44 +0000 Received: by vws3 with SMTP id 3so2430417vws.16 for ; Tue, 01 Jun 2010 09:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=la96XElk1NNmxDuL6y1VkV0Bt3zRxJOxTZiVmosBBBM=; b=e3yEHW1DpAecT0Ago9PGqR26lZxt2Yt1ZVG5PBSaKoRWUj5iXvbXf1aDWGbiox3Q88 +WiPapeZh4Y1ru5lQXTKlv1WIuFGWVpoHL0tnr0QDH0ln+V47PUb8CmacyUL2OLlBIj/ 6jS6zIlb5ef+EQtR5RHrhFKq7p2GsbWPN/2ZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=vvadpt+Ni/Fp0PiZqY6hznbJGGEy2AWI9khVd7RcFUaMDBMVLD3xbgnJIKDbcFLlO9 kV8LonSiO9K/1uT3dbWuC6B9WEJVBcgUZoEWmCx5utwkBJhEh5IlrDewCCdv6GFUSF9L y9WqqTv4uvsU2r8kq+rfPS8zRC/y98XTd0Tyc= Received: by 10.224.72.200 with SMTP id n8mr2515938qaj.294.1275409943143; Tue, 01 Jun 2010 09:32:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.40.16 with HTTP; Tue, 1 Jun 2010 09:32:03 -0700 (PDT) In-Reply-To: References: <0C62EB6A-3BE7-4DBC-8F9E-265332E9954D@objectstyle.org> <6BD138C7-4D75-4F63-8066-E70BDE57BE6F@objectstyle.org> <00633E8B-0BA5-4900-AE11-B74C6812BF5F@objectstyle.org> From: Mike Kienenberger Date: Tue, 1 Jun 2010 12:32:03 -0400 Message-ID: Subject: Re: Vertical inheritance To: dev@cayenne.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org I'm not complete certain I understand the design -- I don't have any experience with single-table inheritance. It sounds ok for as much as I do understand. The only concern I have is that the wording below seems to indicate that only two tables are involved (the root table and the subclass table), but any vertical inheritance deeper than two would involve more tables (N classes deep is N tables). I'm 99.9% certain that you already know this, so I am certain that I'm just misreading your message. But I figure I better ask just in case I'm wrong. On Tue, Jun 1, 2010 at 9:38 AM, Andrus Adamchik wrote: > > On May 31, 2010, at 9:11 AM, Andrus Adamchik wrote: > >> BTW, semantically "vertical inheritance with discriminator" is essentially >> single-table inheritance with flattened attributes in subclasses. Which >> Cayenne supports already, but without any special optimizations for >> wide|deep hierarchies. > > Pounding on this idea some more ... Since we can't get away from using > entity qualifier (discriminator) at least in some cases for performance > reasons, and I hate to add multiple strategies, maybe we do make the > qualifier required and treat vertical as a special case of single table with > subclasses mapped to the same root table, and having flattened attributes > mapped to subclass-specific table. The benefits of that are: > > * No implicit inheritance relationship from super to sub table. It is > explicitly mapped inside flattened attributes. > * More intuitive mapping, easier to visualize attributes, as all attributes > are rooted in the same base table. > * Can potentially handle more than one joined table per subclass, or the > same join table for multiple subclasses, or a mix of single table mapping > with joined table mapping. I.e. in the spirit of Cayenne, we'd allow users > to follow a generic DB semantics in their mapping instead of forcing an > arbitrary ORM concepts on a (legacy) DB schema. > * No new concepts for the backend or Modeler to deal with. > > Now we still need to do some work with this design: > > * Make sure SELECT/INSERT/DELETE/UPDATE work correctly with flattened > attributes over 1..1 relationships, and especially when inheritance is > involved. > * Add convenience Modeler methods to flatten all attributes at once for a > given relationship to simplify subclass mapping. > * Add performance optimizations per Mike's idea, limiting the number of > joins done in a single query. > > Mike, do you see any holes in this design? > > Cheers, > Andrus > >