Kris, Do you have a self-contained, compilable sample i could compare to the one i made? i can craft one from your snippet below, but it'd be a better comparison if you had one already.
Best wishes, --greg On Tue, Jun 23, 2009 at 2:21 PM, Kris Nuttycombe <kris.nuttyco...@gmail.com>wrote: > > Oops, forgot a member of the hierarchy, inline below: > > On Tue, Jun 23, 2009 at 3:19 PM, Kris > Nuttycombe<kris.nuttyco...@gmail.com> wrote: > > I'm just so puzzled by this thread because I have the following entity > > hierarchy in my app: > > > > @Entity > > @Inheritance(strategy = InheritanceType.JOINED) > > @Table(name = "payment_source_transaction") > > public abstract class PaymentSourceTransaction<T extends > PaymentSource<T>> > > extends SubscriptionTransaction implements > > MonetaryTransaction<T>, Serializable { > > > > @ManyToOne(cascade = {CascadeType.MERGE, CascadeType.PERSIST}, > > optional = false, targetEntity = PaymentSource.class) > > private T paymentSource; > > > > ... > > } > > > > @Entity > > public abstract class CreditCardTransaction extends > > PaymentSourceTransaction<CreditCard> { ... } > > > > @MappedSuperclass > public abstract class VoidableCCTransaction extends > CreditCardTransaction implements Serializable { ... } > > @OneToOne(cascade = {CascadeType.MERGE, CascadeType.PERSIST}, > mappedBy="voidedTransaction") > private CCVoidTransaction voidTransaction; > > > @Entity > > public class CCAuthTransaction extends VoidableCCTransaction > > implements AuthTransaction<CreditCard>, Divisional, Serializable { .. > > } > > > > @Entity > > @Inheritance(strategy = InheritanceType.SINGLE_TABLE) > > public abstract class CCCaptureTransaction extends > > VoidableCCTransaction implements Serializable, > > CaptureTransaction<CreditCard> { > > private static final long serialVersionUID = 1L; > > > > @OneToOne(cascade = {CascadeType.PERSIST, CascadeType.MERGE}) > > private CCAuthTransaction authTransaction; > > > > ... > > } > > > > @Entity > > public class EcometryCaptureTransaction extends CCCaptureTransaction > > implements EcometryOrder, Serializable { ... } > > > > @Entity > > @Inheritance(strategy = InheritanceType.JOINED) > > public abstract class PaymentSource<T extends PaymentSource<T>> > > extends UUEntity implements MutationControlled<T>, Serializable { ... > > } > > > > @Entity > > public class CreditCard extends PaymentSource<CreditCard> implements > > Addressable, Serializable { ... } > > > > @Entity > > public class CheckingAccount extends PaymentSource<CheckingAccount> > > implements Serializable { ... } > > > > This works for me without difficulty. What am I missing that is > > different about this scheme than the one that you describe? > > > > Kris > > > > > > > > On Tue, Jun 23, 2009 at 11:29 AM, Meredith > > Gregory<lgreg.mered...@gmail.com> wrote: > >> Derek, > >> > >> i completely concur. i wanted to give it a serious go, however, before i > >> abandoned it. The issue is that so much of the incumbent technology goes > >> across this object-relational boundary, i needed a simple case to > justify > >> walking away from this technology. This example provides it. To see just > how > >> non-complex it is, let me state it in common sense terms. > >> > >> Suppose we are building an app for a manufacturing firm, and the firm > ships > >> out its goods in different kinds of containers: plastic-coated cardboard > >> boxes, metal boxes, etc. > >> Suppose that different kinds of materials go into different kinds of > boxes, > >> and sometimes medicinal or toxic substances go into these containers; > but, > >> every container gets a manifest. When the container contains these > materials > >> that need to be handled with care or attention, the manifest is a > special > >> kind of certified manifest. > >> > >> We might imagine that this firm has already constructed an object model > that > >> looks like > >> > >> abstract class Container { ...; Manifest getManifest(); void > setManifest( > >> Manifest manifest ); ... } > >> class CardboardContainer extends Container { ... } > >> class MetalContainer extends Container { ... } > >> abstract class Manifest { ... } > >> class StdManifest extends Manifest { ... } > >> class CertifiedManifest extends Manifest { ... } > >> > >> We need to work with their existing infrastructure. However, this > >> situation/model breaks Hibernate's implementation of JPA. That such a > simple > >> situation would cause problems indicates to me that these technologies > have > >> never been used in any significant way in production -- otherwise they > would > >> have bumped into such a common case. If i'm wrong about something, here, > i'd > >> love to be disabused of my misunderstanding(s). Currently, i feel i have > >> enough justification to go to a different kind of solution, such as a > >> LINQ-based solution. > >> > >> Best wishes, > >> > >> --greg > >> > >> On Mon, Jun 22, 2009 at 5:46 PM, Derek Chen-Becker < > dchenbec...@gmail.com> > >> wrote: > >>> > >>> For sufficiently complex relationships, JPA is not a good fit. Beyond a > >>> certain point it's usually simpler to roll your own. I think that this > is > >>> somewhat of a failing of the model, but it's not a simple problem to > solve > >>> in the generic case. > >>> > >>> Derek > >>> > >>> On Mon, Jun 22, 2009 at 6:45 PM, Derek Chen-Becker < > dchenbec...@gmail.com> > >>> wrote: > >>>> > >>>> Ah, sorry, I lost track of the thread. > >>>> > >>>> On Mon, Jun 22, 2009 at 4:55 PM, Meredith Gregory > >>>> <lgreg.mered...@gmail.com> wrote: > >>>>> > >>>>> Derek, > >>>>> > >>>>> You are correct and i noted and reported this on Scala on Friday. > >>>>> However, if you have a chain of the form > >>>>> > >>>>> AbstractClass <- Class <-contains- AbstractClass <-Class <-contains- > ... > >>>>> > >>>>> The @MappedSuperclass solution fails at level 2. > >>>>> > >>>>> Best wishes, > >>>>> > >>>>> --greg > >>>>> > >>>>> On Mon, Jun 22, 2009 at 3:52 PM, Derek Chen-Becker > >>>>> <dchenbec...@gmail.com> wrote: > >>>>>> > >>>>>> Something I just want to throw out into the discussion: Since you're > >>>>>> using table-per-class, having a @Table annotation on > AbstractContainer > >>>>>> doesn't do anything since abstract classes can't have instances. > Tables are > >>>>>> only generated for abstract classes if you're using a JOINED > inheritance > >>>>>> strategy. You might want to look at using the MappedSuperclass > annotation > >>>>>> for the abstract base class instead. If I change the > AbstractContainer def > >>>>>> to: > >>>>>> > >>>>>> @MappedSuperclass > >>>>>> public abstract class AbstractContainer implements > java.io.Serializable > >>>>>> { > >>>>>> > >>>>>> and then modify MySampleFuContainer to: > >>>>>> > >>>>>> public class MySampleFuContainer extends AbstractContainer { > >>>>>> > >>>>>> then I seem to get the proper schema: > >>>>>> > >>>>>> create table lingo_production.MySampleFuContainer_table ( > >>>>>> id varchar(255) not null, > >>>>>> uuid varchar(255), > >>>>>> mysamplingmumble__idSuper varchar(255), > >>>>>> primary key (id), > >>>>>> unique (uuid) > >>>>>> ); > >>>>>> > >>>>>> > >>>>>> Having said that, I think that the behavior you're currently seeing > >>>>>> appears to be a bug. > >>>>>> > >>>>>> Derek > >>>>>> > >>>>>> On Mon, Jun 22, 2009 at 3:43 PM, Meredith Gregory > >>>>>> <lgreg.mered...@gmail.com> wrote: > >>>>>>> > >>>>>>> Kris, > >>>>>>> > >>>>>>> Here is a link to the self-contained example that now uses just > Java. > >>>>>>> i included the target dir in the repo to speed up investigation, > but you can > >>>>>>> just blow that away and build from scratch. The example is > currently written > >>>>>>> to Java1.6, but also exhibits the same behavior under Java1.5. To > run the > >>>>>>> example > >>>>>>> > >>>>>>> > svn co > >>>>>>> > > http://svn.biosimilarity.com/src/open/codesamples/trunk/hibernate > >>>>>>> ... > >>>>>>> > env PATH=<path-to-java1.6>:$PATH JAVA_HOME=<path-to-java1.6> mvn > >>>>>>> > clean compile process-classes > >>>>>>> > >>>>>>> If you switch comment and decl at line 22 in > >>>>>>> src/main/java/maxb/hbex2/MySampleFuContainer.java then you see the > error. > >>>>>>> The schema goes from > >>>>>>> > >>>>>>> create table lingo_production.MySampleFuContainer_table ( > >>>>>>> id_AbstractContainer varchar(255) not null, > >>>>>>> varchar(255) not null, > >>>>>>> uuid varchar(255), > >>>>>>> mysamplingmumble__idSuper varchar(255), > >>>>>>> primary key (id), > >>>>>>> unique (uuid) > >>>>>>> ); > >>>>>>> > >>>>>>> to > >>>>>>> > >>>>>>> create table lingo_production.MySampleFuContainer_table ( > >>>>>>> id_AbstractContainer varchar(255) not null, > >>>>>>> id varchar(255), > >>>>>>> mysamplingmumble_ tinyblob, > >>>>>>> uuid varchar(255), > >>>>>>> primary key (id_AbstractContainer), > >>>>>>> unique (id_AbstractContainer) > >>>>>>> ); > >>>>>>> > >>>>>>> Best wishes, > >>>>>>> > >>>>>>> --greg > >>>>>>> > >>>>>>> On Mon, Jun 22, 2009 at 1:38 PM, Meredith Gregory > >>>>>>> <lgreg.mered...@gmail.com> wrote: > >>>>>>>> > >>>>>>>> Kris, > >>>>>>>> > >>>>>>>> Thanks for the suggestion. i've now got a tiny little example that > >>>>>>>> compiles on its own that illustrates the problem. Changing the > inheritance > >>>>>>>> strategy to JOINED makes no difference. Hibernate still does the > wrong > >>>>>>>> thing. > >>>>>>>> > >>>>>>>> Best wishes, > >>>>>>>> > >>>>>>>> --greg > >>>>>>>> > >>>>>>>> On Mon, Jun 22, 2009 at 8:55 AM, Kris Nuttycombe > >>>>>>>> <kris.nuttyco...@gmail.com> wrote: > >>>>>>>>> > >>>>>>>>> This may be off the mark, but I'm wondering if the reason that > >>>>>>>>> you're > >>>>>>>>> having difficulty with the parallel inheritance hierarchy problem > is > >>>>>>>>> not your use of TABLE_PER_CLASS inheritance. In my application, I > >>>>>>>>> have > >>>>>>>>> a similar construct, but I am using JOINED_TABLE inheritance. > This > >>>>>>>>> allows for a normal foreign key relationship to be created in the > >>>>>>>>> database between C2_table and the base table for CThing, with the > >>>>>>>>> result that Hibernate will generate the query for CThing member > as a > >>>>>>>>> union. Using table per class inheritance, I would expect > Hibernate > >>>>>>>>> to > >>>>>>>>> need to synthesize an additional dtype field in C2_table along > with > >>>>>>>>> the key column in order to enforce the uniqueness of the keys to > the > >>>>>>>>> joined entities, and I don't believe that it does this. > >>>>>>>>> > >>>>>>>>> I'm not sure how the fact that the code is generated is > particularly > >>>>>>>>> relevant; surely if it's possible to hand-write a successful > >>>>>>>>> solution, > >>>>>>>>> then your code generator could be made aware of how to construct > a > >>>>>>>>> viable solution? > >>>>>>>>> > >>>>>>>>> Kris > >>>>>>>>> > >>>>>>>>> On Fri, Jun 19, 2009 at 8:47 PM, Meredith > >>>>>>>>> Gregory<lgreg.mered...@gmail.com> wrote: > >>>>>>>>> > All, > >>>>>>>>> > > >>>>>>>>> > i had a similar problem and found the source of the issues. > Spse > >>>>>>>>> > you have a > >>>>>>>>> > container hierarchy (CTop <- C2) side-by-side with a contained > >>>>>>>>> > hierarchy > >>>>>>>>> > (CThing <- CThing1). The inheritance at the top of the > container > >>>>>>>>> > hierarchy, > >>>>>>>>> > CTop, causes hibernate to bail on tracking the relations and > punt > >>>>>>>>> > to > >>>>>>>>> > embedded values instead. Rewriting the top to be a > >>>>>>>>> > @MappedSuperClass fixes > >>>>>>>>> > the problem in this specific case. However, if your hierarchy > is > >>>>>>>>> > deep, > >>>>>>>>> > you're screwed. > >>>>>>>>> > > >>>>>>>>> > If anybody has a suggestion for a workaround, i'm all ears. The > >>>>>>>>> > problem is > >>>>>>>>> > that it would appear that both Mr Crowley and i are generating > >>>>>>>>> > Java + JPA > >>>>>>>>> > code. So, the solution needs to be algorithmic and not 1-off. > >>>>>>>>> > > >>>>>>>>> > Perhaps the best solution is to find an alternative to > hibernate > >>>>>>>>> > as this is > >>>>>>>>> > a particularly irritating bug. > >>>>>>>>> > > >>>>>>>>> > Best wishes, > >>>>>>>>> > > >>>>>>>>> > --greg > >>>>>>>>> > > >>>>>>>>> > @Entity > >>>>>>>>> > @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) > >>>>>>>>> > abstract class CTop { > >>>>>>>>> > ... > >>>>>>>>> > @Id > >>>>>>>>> > @GeneratedValue(generator = "system-uuid") > >>>>>>>>> > @GenericGenerator(name = "system-uuid", strategy = "uuid") > >>>>>>>>> > private String id_CTop; > >>>>>>>>> > } > >>>>>>>>> > > >>>>>>>>> > @Entity > >>>>>>>>> > @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) > >>>>>>>>> > abstract class CThing { > >>>>>>>>> > ... > >>>>>>>>> > @Id > >>>>>>>>> > @GeneratedValue(generator = "system-uuid") > >>>>>>>>> > @GenericGenerator(name = "system-uuid", strategy = "uuid") > >>>>>>>>> > private String id_CThing; > >>>>>>>>> > } > >>>>>>>>> > > >>>>>>>>> > @Entity > >>>>>>>>> > @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) > >>>>>>>>> > @Table(name = "C2_table", catalog = "mydb_production", > >>>>>>>>> > uniqueConstraints = { > >>>>>>>>> > @UniqueConstraint(columnNames = "uuid") }) > >>>>>>>>> > class C2 extends CTop { > >>>>>>>>> > CThing thing; > >>>>>>>>> > ... > >>>>>>>>> > @OneToOne > >>>>>>>>> > @JoinColumn > >>>>>>>>> > public CThing getThing() { > >>>>>>>>> > return this.thing; > >>>>>>>>> > } > >>>>>>>>> > public void setThing( CThing thing ) { > >>>>>>>>> > this.thing = thing; > >>>>>>>>> > } > >>>>>>>>> > > >>>>>>>>> > @Column(name = "uuid", unique = false, nullable = true, > insertable > >>>>>>>>> > = true, > >>>>>>>>> > updatable = true) > >>>>>>>>> > public String getUuid() { > >>>>>>>>> > return this.uuid; > >>>>>>>>> > } > >>>>>>>>> > > >>>>>>>>> > public void setUuid(String uuid) { > >>>>>>>>> > this.uuid = uuid; > >>>>>>>>> > } > >>>>>>>>> > > >>>>>>>>> > @Id > >>>>>>>>> > @GeneratedValue(generator = "system-uuid") > >>>>>>>>> > @GenericGenerator(name = "system-uuid", strategy = "uuid") > >>>>>>>>> > @Column(name = "id", unique = false, nullable = true, > >>>>>>>>> > insertable = true, > >>>>>>>>> > updatable = true) > >>>>>>>>> > public String getId() { > >>>>>>>>> > return this.id; > >>>>>>>>> > } > >>>>>>>>> > > >>>>>>>>> > } > >>>>>>>>> > > >>>>>>>>> > @Entity > >>>>>>>>> > @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) > >>>>>>>>> > @Table(name = "CThing1_table", catalog = "mydb_production", > >>>>>>>>> > uniqueConstraints = { @UniqueConstraint(columnNames = "uuid") > }) > >>>>>>>>> > class CThing1 extends CThing { > >>>>>>>>> > ... > >>>>>>>>> > // lots of ground type fields > >>>>>>>>> > > >>>>>>>>> > @Column(name = "uuid", unique = false, nullable = true, > insertable > >>>>>>>>> > = true, > >>>>>>>>> > updatable = true) > >>>>>>>>> > public String getUuid() { > >>>>>>>>> > return this.uuid; > >>>>>>>>> > } > >>>>>>>>> > > >>>>>>>>> > public void setUuid(String uuid) { > >>>>>>>>> > this.uuid = uuid; > >>>>>>>>> > } > >>>>>>>>> > > >>>>>>>>> > @Id > >>>>>>>>> > @GeneratedValue(generator = "system-uuid") > >>>>>>>>> > @GenericGenerator(name = "system-uuid", strategy = "uuid") > >>>>>>>>> > @Column(name = "id", unique = false, nullable = true, > >>>>>>>>> > insertable = true, > >>>>>>>>> > updatable = true) > >>>>>>>>> > public String getId() { > >>>>>>>>> > return this.id; > >>>>>>>>> > } > >>>>>>>>> > > >>>>>>>>> > } > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > On Tue, Jun 16, 2009 at 1:45 PM, Derek Chen-Becker > >>>>>>>>> > <j...@chen-becker.org> > >>>>>>>>> > wrote: > >>>>>>>>> >> > >>>>>>>>> >> John Nilsson wrote: > >>>>>>>>> >> > Hi, > >>>>>>>>> >> > > >>>>>>>>> >> > I think the showSql property has been deprecated in favor of > >>>>>>>>> >> > log4j > >>>>>>>>> >> > loggers. > >>>>>>>>> >> > > >>>>>>>>> >> > If you set the log4j level to TRACE for org.hibernate you'll > >>>>>>>>> >> > get > >>>>>>>>> >> > everything Hibernate has to say about what it is doing. > Can't > >>>>>>>>> >> > remember > >>>>>>>>> >> > which one it is, but I know one of the loggers will give you > >>>>>>>>> >> > the > >>>>>>>>> >> > values used in queries at the TRACE level. > >>>>>>>>> >> > >>>>>>>>> >> Good to know. Thanks! > >>>>>>>>> >> > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > -- > >>>>>>>>> > L.G. Meredith > >>>>>>>>> > Managing Partner > >>>>>>>>> > Biosimilarity LLC > >>>>>>>>> > 1219 NW 83rd St > >>>>>>>>> > Seattle, WA 98117 > >>>>>>>>> > > >>>>>>>>> > +1 206.650.3740 > >>>>>>>>> > > >>>>>>>>> > http://biosimilarity.blogspot.com > >>>>>>>>> > > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> L.G. Meredith > >>>>>>>> Managing Partner > >>>>>>>> Biosimilarity LLC > >>>>>>>> 1219 NW 83rd St > >>>>>>>> Seattle, WA 98117 > >>>>>>>> > >>>>>>>> +1 206.650.3740 > >>>>>>>> > >>>>>>>> http://biosimilarity.blogspot.com > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> L.G. Meredith > >>>>>>> Managing Partner > >>>>>>> Biosimilarity LLC > >>>>>>> 1219 NW 83rd St > >>>>>>> Seattle, WA 98117 > >>>>>>> > >>>>>>> +1 206.650.3740 > >>>>>>> > >>>>>>> http://biosimilarity.blogspot.com > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> L.G. Meredith > >>>>> Managing Partner > >>>>> Biosimilarity LLC > >>>>> 1219 NW 83rd St > >>>>> Seattle, WA 98117 > >>>>> > >>>>> +1 206.650.3740 > >>>>> > >>>>> http://biosimilarity.blogspot.com > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > >> -- > >> L.G. Meredith > >> Managing Partner > >> Biosimilarity LLC > >> 1219 NW 83rd St > >> Seattle, WA 98117 > >> > >> +1 206.650.3740 > >> > >> http://biosimilarity.blogspot.com > >> > >> >> > >> > > > > > > -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---