[Lift] Re: [scala] JPA question

[Derek Chen-Becker]

Well, in my real-world experience I've never had very complex models and
I've never used TABLE-PER-CLASS either, so I don't really have a feel for
what's not possible. Generally I think that JPA (which is a subset of
Hibernate) covers a good portion of people's needs for ORM, but it
definitely has some big missing functionality (e.g. no ordered collections
until JPA 2). I think that in this case Greg is pushing the limits on a
relatively unused corner of JPA (I've never seen someone use TABLE-PER-CLASS
before) and he's hitting some bugs. I want to make clear that I think that
what Greg is attempting is entirely possible. My earlier comment about
rolling your own ORM was because I misunderstood what he was doing with
abstract classes. In my mind, there would be a couple of places where you
might want to roll your own stuff:


   1. An existing schema that doesn't map well to an object graph. We have a
   legacy database at work where the brilliant developers decided that nothing
   should be normalized and data can exist in one of four tables based on some
   arcane business logic. You can still build an ORM layer on something like
   this, but essentially all you're doing is creating a thin wrapper on
   ResultSets
   2. You have very specific data that you need to retrieve with possibly
   complex joins, and you need it to be as performant as possible. There are
   some tricks you can do with EJB QL to make it prefetch things, but often you
   can end up with multiple round trips to the database and/or data that you
   don't need being fetched. In certain scenarios I could see this being an
   issue.

This list isn't intended to be exhaustive, these are just the top two that
come to mind. In terms of Hibernate vs others like JPOX, TopLink, etc, I'd
say that Hibernate is a first-class provider and at least equal to the
others.

Derek

On Wed, Jun 24, 2009 at 2:21 AM, TSP  wrote:

>
> Derek
> Would you distinguish between what is achievable in a specific ORM
> such as Hibernate from JPA in this statement or would you think it
> applies to all. I've got to "go with hibernate" in any case because of
> widespread use of UserTypes. Unlike Greg, in my case I can hand-craft
> all my hibernate xml files if I need.
>
> Tim
>
> On Jun 23, 1:46 am, Derek Chen-Becker  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<
> http://svn.biosimilarity.com/src/open/codesamples/trunk/hibernate/>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 Ja

[Lift] Re: [scala] JPA question

[TSP]

Derek
Would you distinguish between what is achievable in a specific ORM
such as Hibernate from JPA in this statement or would you think it
applies to all. I've got to "go with hibernate" in any case because of
widespread use of UserTypes. Unlike Greg, in my case I can hand-craft
all my hibernate xml files if I need.

Tim

On Jun 23, 1:46 am, Derek Chen-Becker  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 
> 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  >> > 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,
>
>  Hereis
>   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 JAVA_HOME= 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 genera

[Lift] Re: [scala] JPA question

[Oliver Lambert]

Actually, I don't think I would be looking at @MappedSuperclass either.
Whats your database schema? Is it always a Legacy database or are you
creating it new?
Are the java entities you are trying to create, read only?
Why aren't you using Scala's JPA?
If you are creating a complex parent-child relationships, cant you use
one-many relationships in hibernate
rather than bothering with Hibernates object-superclass implementation?

I have seen Hibernate used to map complex relationships in production, but
when I see an OR-mapping
problem I always try KISS principles on it first. Sometimes this involves
creating views, sometimes it involves just completely lying to Hibernate
about the underling data structure and creating
a Read only entity.
For example I have a the following entity that maps to a select (not a table
or view)
class RoEntity {
  @Id
  var entityId: Long = _
...
}
EM.createNativeQuery[RoEntity](nativeQueryStr, classOf[RoEntity])

If I want to save it, I populate an entity that really has an underlying
table.

cheers
Oliver

On Wed, Jun 24, 2009 at 9:55 AM, Oliver Lambert  wrote:

> I don't understand from the code sample why AbstractContainer has to be an
> entity or
> have a table or id annotation. I'd be looking at just using the
> @MappedSuperclass annotation.
>
>
> On Wed, Jun 24, 2009 at 9:27 AM, Meredith Gregory <
> lgreg.mered...@gmail.com> wrote:
>
>> Kris,
>>
>> Thanks for this code sample. i will study and see if it offers a way
>> around the conundrum. In the meantime, here's a code 
>> sampleillustrating
>>  exactly what i'm talking about.
>>
>> 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 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>> PaymentSource>
>>> >extends SubscriptionTransaction implements
>>> > MonetaryTransaction, Serializable {
>>> >
>>> >@ManyToOne(cascade = {CascadeType.MERGE, CascadeType.PERSIST},
>>> > optional = false, targetEntity = PaymentSource.class)
>>> >private T paymentSource;
>>> >
>>> >...
>>> > }
>>> >
>>> > @Entity
>>> > public abstract class CreditCardTransaction extends
>>> > PaymentSourceTransaction { ... }
>>> >
>>>
>>> @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, Divisional, Serializable { ..
>>> > }
>>> >
>>> > @Entity
>>> > @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
>>> > public abstract class CCCaptureTransaction extends
>>> > VoidableCCTransaction implements Serializable,
>>> > CaptureTransaction {
>>> >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>
>>> > extends UUEntity implements MutationControlled, Serializable { ...
>>> > }
>>> >
>>> > @Entity
>>> > public class CreditCard extends PaymentSource implements
>>> > Addressable, Serializable { ... }
>>> >
>>> > @Entity
>>> > public class CheckingAccount extends PaymentSource
>>> > 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 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.
>>> >

[Lift] Re: [scala] JPA question

[Meredith Gregory]

Oliver,

Thanks. This proposal has been put forward before.

   - The code is generated. If the top class is annotated @MappedSuperclass,
   why not label every abstract class that is top of its hierarchy
   @MappedSuperclass. That's the simplest change to the compilation strategy
   that generates this code.
   - This fails for the contained element. Specifically, if you also label
   the top of the contained element hierarchy @MappedSuperclass, then hibernate
   fails to be able to find the Id of the subclasses.
   - Futher, how does the compilation scheme know which top class is
   contained. That's not possible because someone could always come along and
   add another class that was a container. So, this fails to be compositional,
   in the extreme.


Best wishes,

--greg

On Tue, Jun 23, 2009 at 4:55 PM, Oliver Lambert  wrote:

> I don't understand from the code sample why AbstractContainer has to be an
> entity or
> have a table or id annotation. I'd be looking at just using the
> @MappedSuperclass annotation.
>
>
> On Wed, Jun 24, 2009 at 9:27 AM, Meredith Gregory <
> lgreg.mered...@gmail.com> wrote:
>
>> Kris,
>>
>> Thanks for this code sample. i will study and see if it offers a way
>> around the conundrum. In the meantime, here's a code 
>> sampleillustrating
>>  exactly what i'm talking about.
>>
>> 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 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>> PaymentSource>
>>> >extends SubscriptionTransaction implements
>>> > MonetaryTransaction, Serializable {
>>> >
>>> >@ManyToOne(cascade = {CascadeType.MERGE, CascadeType.PERSIST},
>>> > optional = false, targetEntity = PaymentSource.class)
>>> >private T paymentSource;
>>> >
>>> >...
>>> > }
>>> >
>>> > @Entity
>>> > public abstract class CreditCardTransaction extends
>>> > PaymentSourceTransaction { ... }
>>> >
>>>
>>> @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, Divisional, Serializable { ..
>>> > }
>>> >
>>> > @Entity
>>> > @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
>>> > public abstract class CCCaptureTransaction extends
>>> > VoidableCCTransaction implements Serializable,
>>> > CaptureTransaction {
>>> >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>
>>> > extends UUEntity implements MutationControlled, Serializable { ...
>>> > }
>>> >
>>> > @Entity
>>> > public class CreditCard extends PaymentSource implements
>>> > Addressable, Serializable { ... }
>>> >
>>> > @Entity
>>> > public class CheckingAccount extends PaymentSource
>>> > 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 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
>>> >

[Lift] Re: [scala] JPA question

[Meredith Gregory]

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
wrote:

>
> Oops, forgot a member of the hierarchy, inline below:
>
> On Tue, Jun 23, 2009 at 3:19 PM, Kris
> Nuttycombe 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 PaymentSource>
> >extends SubscriptionTransaction implements
> > MonetaryTransaction, Serializable {
> >
> >@ManyToOne(cascade = {CascadeType.MERGE, CascadeType.PERSIST},
> > optional = false, targetEntity = PaymentSource.class)
> >private T paymentSource;
> >
> >...
> > }
> >
> > @Entity
> > public abstract class CreditCardTransaction extends
> > PaymentSourceTransaction { ... }
> >
>
> @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, Divisional, Serializable { ..
> > }
> >
> > @Entity
> > @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
> > public abstract class CCCaptureTransaction extends
> > VoidableCCTransaction implements Serializable,
> > CaptureTransaction {
> >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>
> > extends UUEntity implements MutationControlled, Serializable { ...
> > }
> >
> > @Entity
> > public class CreditCard extends PaymentSource implements
> > Addressable, Serializable { ... }
> >
> > @Entity
> > public class CheckingAccount extends PaymentSource
> > 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 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
> >>

[Lift] Re: [scala] JPA question

[Oliver Lambert]

I don't understand from the code sample why AbstractContainer has to be an
entity or
have a table or id annotation. I'd be looking at just using the
@MappedSuperclass annotation.

On Wed, Jun 24, 2009 at 9:27 AM, Meredith Gregory
wrote:

> Kris,
>
> Thanks for this code sample. i will study and see if it offers a way around
> the conundrum. In the meantime, here's a code 
> sampleillustrating
>  exactly what i'm talking about.
>
> 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 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> PaymentSource>
>> >extends SubscriptionTransaction implements
>> > MonetaryTransaction, Serializable {
>> >
>> >@ManyToOne(cascade = {CascadeType.MERGE, CascadeType.PERSIST},
>> > optional = false, targetEntity = PaymentSource.class)
>> >private T paymentSource;
>> >
>> >...
>> > }
>> >
>> > @Entity
>> > public abstract class CreditCardTransaction extends
>> > PaymentSourceTransaction { ... }
>> >
>>
>> @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, Divisional, Serializable { ..
>> > }
>> >
>> > @Entity
>> > @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
>> > public abstract class CCCaptureTransaction extends
>> > VoidableCCTransaction implements Serializable,
>> > CaptureTransaction {
>> >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>
>> > extends UUEntity implements MutationControlled, Serializable { ...
>> > }
>> >
>> > @Entity
>> > public class CreditCard extends PaymentSource implements
>> > Addressable, Serializable { ... }
>> >
>> > @Entity
>> > public class CheckingAccount extends PaymentSource
>> > 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 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,
>> her

[Lift] Re: [scala] JPA question

[Meredith Gregory]

Kris,

Thanks for this code sample. i will study and see if it offers a way around
the conundrum. In the meantime, here's a code
sampleillustrating
exactly what i'm talking about.

Best wishes,

--greg

On Tue, Jun 23, 2009 at 2:21 PM, Kris Nuttycombe
wrote:

>
> Oops, forgot a member of the hierarchy, inline below:
>
> On Tue, Jun 23, 2009 at 3:19 PM, Kris
> Nuttycombe 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 PaymentSource>
> >extends SubscriptionTransaction implements
> > MonetaryTransaction, Serializable {
> >
> >@ManyToOne(cascade = {CascadeType.MERGE, CascadeType.PERSIST},
> > optional = false, targetEntity = PaymentSource.class)
> >private T paymentSource;
> >
> >...
> > }
> >
> > @Entity
> > public abstract class CreditCardTransaction extends
> > PaymentSourceTransaction { ... }
> >
>
> @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, Divisional, Serializable { ..
> > }
> >
> > @Entity
> > @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
> > public abstract class CCCaptureTransaction extends
> > VoidableCCTransaction implements Serializable,
> > CaptureTransaction {
> >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>
> > extends UUEntity implements MutationControlled, Serializable { ...
> > }
> >
> > @Entity
> > public class CreditCard extends PaymentSource implements
> > Addressable, Serializable { ... }
> >
> > @Entity
> > public class CheckingAccount extends PaymentSource
> > 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 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 

[Lift] Re: [scala] JPA question

[Kris Nuttycombe]

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>
extends SubscriptionTransaction implements
MonetaryTransaction, Serializable {

@ManyToOne(cascade = {CascadeType.MERGE, CascadeType.PERSIST},
optional = false, targetEntity = PaymentSource.class)
private T paymentSource;

...
}

@Entity
public abstract class CreditCardTransaction extends
PaymentSourceTransaction { ... }

@Entity
public class CCAuthTransaction extends VoidableCCTransaction
implements AuthTransaction, Divisional, Serializable { ..
}

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
public abstract class CCCaptureTransaction extends
VoidableCCTransaction implements Serializable,
CaptureTransaction {
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>
extends UUEntity implements MutationControlled, Serializable { ...
}

@Entity
public class CreditCard extends PaymentSource implements
Addressable, Serializable { ... }

@Entity
public class CheckingAccount extends PaymentSource
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 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 
> 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 
>> wrote:
>>>
>>> Ah, sorry, I lost track of the thread.
>>>
>>> On Mon, Jun 22, 2009 at 4:55 PM, Meredith Gregory
>>>  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
  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 abst

[Lift] Re: [scala] JPA question

[Kris Nuttycombe]

Oops, forgot a member of the hierarchy, inline below:

On Tue, Jun 23, 2009 at 3:19 PM, Kris
Nuttycombe 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>
>        extends SubscriptionTransaction implements
> MonetaryTransaction, Serializable {
>
>   �...@manytoone(cascade = {CascadeType.MERGE, CascadeType.PERSIST},
> optional = false, targetEntity = PaymentSource.class)
>    private T paymentSource;
>
>    ...
> }
>
> @Entity
> public abstract class CreditCardTransaction extends
> PaymentSourceTransaction { ... }
>

@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, Divisional, Serializable { ..
> }
>
> @Entity
> @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
> public abstract class CCCaptureTransaction extends
> VoidableCCTransaction implements Serializable,
> CaptureTransaction {
>    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>
> extends UUEntity implements MutationControlled, Serializable { ...
> }
>
> @Entity
> public class CreditCard extends PaymentSource implements
> Addressable, Serializable { ... }
>
> @Entity
> public class CheckingAccount extends PaymentSource
> 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 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 
>> 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 
>>> wrote:

 Ah, sorry, I lost track of the thread.

 On Mon, Jun 22, 2009 at 4:55 PM, Meredith Gregory
  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 solu

[Lift] Re: [scala] JPA question

[Meredith Gregory]

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.

   1. 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.
   2. 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 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 
> 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,
>
> Hereis
>  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 JAVA_HOME= 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)

[Lift] Re: [scala] JPA question

[Derek Chen-Becker]

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 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 > > 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,

 Hereis 
 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 JAVA_HOME= 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,
>>

[Lift] Re: [scala] JPA question

[Derek Chen-Becker]

Ah, sorry, I lost track of the thread.

On Mon, Jun 22, 2009 at 4:55 PM, Meredith Gregory
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 
> 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,
>>>
>>> Hereis 
>>> 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 JAVA_HOME= 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 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,
>

[Lift] Re: [scala] JPA question

[Meredith Gregory]

P.S. While i am waiting for the Hibernate folks to respond to the issue, i
am looking into Stefan Zeiger's LINQ implementation for Scala more
seriously. If it is reasonably stable, this is a much better target for my
compilation scheme, anyway.

On Mon, Jun 22, 2009 at 3:55 PM, Meredith Gregory
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 
> 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,
>>>
>>> Hereis 
>>> 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 JAVA_HOME= 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 wrote:
> > All,
> >
> > i had a similar problem and found the source of the issues

[Lift] Re: [scala] JPA question

[Meredith Gregory]

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 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 JAVA_HOME= 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 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 s

[Lift] Re: [scala] JPA question

[Derek Chen-Becker]

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
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 JAVA_HOME= 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 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)

[Lift] Re: [scala] JPA question

[Meredith Gregory]

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 JAVA_HOME= 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
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 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

[Lift] Re: [scala] JPA question

[Meredith Gregory]

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
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 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  >
> > wrote:
> >>
> >> John Nilsson wrote:
> >> > Hi,
> >> >
> >> > I think the showSql property has been deprecated in favor of log4j
> >> > loggers.
> >> >
> >> > If you set