[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Looking for hints to map inheritance relationships
|
Thanks Chris. I think maybe AssociationOverride might have been what
I was looking for. But I think you are right... I probably should
just use category from the parent but wasnt sure how eclipselink/jpa
would handle it. Interesting to know that overriding the category
property generates two mappings... especially because there is only a
category_id column created in the product table and not the automobile
table.
This test code is fairly contrived but I'm refactoring my real code to
just use the parent classes property and see where that takes me.
Thanks again for the AssociationOverride hint!
On Fri, Jul 15, 2011 at 10:17 AM, Christopher Delahunt
<christopher.delahunt@xxxxxxxxxx> wrote:
> Hello Phillip,
>
> You are overwriting through java polymorphism when what you seem to have
> been intending is more along the lines of using an AssociationOverride from
> JPA inheritance.
> Even though the Automobile's super.category cannot be accessed from the
> application, it still exists in the in the object, so there are two distinct
> mappings generated; one for this.category and one for super.category.
>
> I am not sure why you have the AutomobileCategory category in Automobile
> when it can just use the category from its parent and then cast it to
> AutomobileCategory using its own overriden get/set methods
> in Automobile. This will cause only 1 mapping to be created as well, which
> seems more what you are intending.
>
> Best Regards,
> Chris
>
> On 15/07/2011 7:43 AM, Phillip Ross wrote:
>
> Yeah so after playing around with this a little more I realize that
> the queried ProductCategory entities do not have the automobile
> entities in their collections because the setCategory method of the
> Automobile class only does the super.category assignment which will
> not handle the addition of the instance to the collection on the
> category side. doing super.setCategory(category) instead of
> super.category = category accomplished this and now the automobile
> instances do show up.
>
> This seems as of it is only a workaround though... with the potential
> to break in other ways. Hrmmmm.
>
> On Fri, Jul 15, 2011 at 6:18 AM, Phillip Ross
> <phillip.w.g.ross@xxxxxxxxx> wrote:
>
>
> I guess I should also point out... the Automobile class has a
> setCategory method which sets this.category but the line below has a
> super.category assignment which is commented out. When this is
> uncommented, the creation of the entities works... but it seems like
> this should not be necessary since the category property of the
> Automobile class is mapped and referencing AutomobileCategory, not
> ProductCategory.
>
> Furthermore, if the super.category assignment is uncommented you can
> see that querying all ProductCategory instances will return two... of
> which one is a concrete Automobile category, but is contains no
> Automobiles in it's collection. Ideally it should... since querying
> for all AutomobileCategories returns the same automobile category
> instance which DOES have the collection populated with Automobile
> instances.
>
> I'm wondering if I'm hitting a bug or maybe just getting too fancy
> with respect to mapping inheritance with JPA :)
>
> On Fri, Jul 15, 2011 at 6:09 AM, Phillip Ross
> <phillip.w.g.ross@xxxxxxxxx> wrote:
>
>
> Thanks for the reply Tom. Here are the annotated property definitions
> from the classes:
>
> Product:
> @JoinColumn(nullable=false)
>
> @ManyToOne(cascade={CascadeType.PERSIST,CascadeType.MERGE,CascadeType.REFRESH})
> protected ProductCategory category;
>
> ProductCategory:
> @OneToMany(mappedBy = "category",
> cascade={CascadeType.PERSIST,CascadeType.MERGE,CascadeType.REFRESH})
> private Set<Product> products;
>
> Automobile:
> @JoinColumn(nullable=false)
>
> @ManyToOne(cascade={CascadeType.PERSIST,CascadeType.MERGE,CascadeType.REFRESH})
> private AutomobileCategory category;
>
> AutomobileCategory:
> @OneToMany(mappedBy = "category",
> cascade={CascadeType.PERSIST,CascadeType.MERGE,CascadeType.REFRESH})
> private Set<Automobile> automobiles;
>
>
> The following is the code that just persists some instances of the entities:
> entityManager.getTransaction().begin();
> AutomobileCategory automobileCategory = new
> AutomobileCategory("AC_" + UUID.randomUUID().toString(), "ENAME",
> "SNAME");
> for (int i = 0; i < 5; i++) {
> Automobile automobile = new Automobile("A_" +
> UUID.randomUUID().toString(), automobileCategory, "ENAME", "SNAME");
> entityManager.persist(automobile);
> }
> entityManager.getTransaction().commit();
>
> And I'm attaching the log as it's probably too big to inline.
>
> I have a full testcase that probably illustrates more of what is going
> on. I'll attach those source files too.
>
> Thanks again
> - Phillip
>
>
> On Thu, Jul 14, 2011 at 8:39 AM, Tom Ware <tom.ware@xxxxxxxxxx> wrote:
>
>
> Hi Phillip,
>
> Can you please post the following:
>
> - examples of how the category fields are mapped in both Product and
> Automobile
> - a code snippet the shows what you are doing
> - logging of the SQL produced and the full exception trace (for logging, use
> persistence unit property eclipselink.logging.level=FINEST)
>
> -Tom
>
> Phillip Ross wrote:
>
>
> Hi all, I'm having a problem with mapping inheritance and not sure if
> things are acting correctly or not. Was hoping for some hints.
>
> The scenario I'm working with is that I have two related entity
> superclasses mapped with an inheritance strategy or JOINED, and there
> is a ManyToOne relationship between the two. The subclass entities
> subclass the superclasses and override the relationship (or at least
> this is what is intended). I had first assumed that when the tables
> were created, a field would be created in both the parents table and
> child table... but it appears that it was only created in the parent
> table. I figured that this was OK since there would be records in the
> parent tables that would map related subclass instances, but when I
> attempt to persist the subclass with the ManyToOne member attribute...
> an exception is thrown caused by a not-null constraint violation
> corresponding to the parent table's FK field. As an experiment, I
> changed the child class to populate the related property field in both
> the superclass and itself, but I'm assuming this won't really work out
> in the future as fetching the correct records may not work either.
>
> To put this in more concrete terms... say I have Product and
> ProductCategory as superclasses. Product has a property called
> category which holds a ProductCategory instance. Automobile
> subclasses Product and AutomobileCategory subclasses ProductCategory.
> The Automobile class defined a property named category and is defined
> to be AutomobileCategory. Since persisting an Automobile and an
> AutomobileCategory would create records in all four tables... shouldnt
> eclipselink know that the category field in the Product table relating
> to ProductCategory be used to map the Automobile instances to the
> AutomobileCategory instances?
>
> I'm hoping someone knoww if I'm trying to map a scenario that's not
> supported or if there is a trick to doing this? Perhaps an
> eclipselink specific trick that goes beyond the JPA spec? If it is
> supported and sounds like a bug... I have a test case to submit :)
>
> Thanks!
> - Phillip
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
>
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
>
