Andreas Erber

Hi there,

I am curious. I have an application with a fairly large hierarchy of entities. They are annotated with javax.persistence and Hibernate annotations. Furthermore, there is a parallel hierarchy of proxy interfaces such that each entity class implements a proxy interface that extends a parent proxy interface that is implemented by the parent class of the entity class .

When I start the app, Hibernate configuration works fine but just before building the SessionFactory I get lots of different javassist exceptions and warnings like, i.e. javassist.bytecode.DuplicateMemberException: duplicate method ... org.hibernate.tuple.entity.PojoEntityTuplizer,main could not create proxy factory for... org.hibernate.HibernateException: Javassist Enhancement failed... It does not happen with all entities of the hierarchy, just a fraction. On different runs of the application the number of affected entities changes as well as their types. Sometimes a type seems to be fine, next time it causes an exception. Nonetheless, Hibernate manages to build the SessionFactory in the end and everything just works fine.

What is happening here?
Is this due to the order the entities are handled by the configuration?
If so, can I force an order that does not lead to exceptions and warnings? (I don't want the users being troubled by output like that)

Thanks for your attention
CU
Froestel

Hi mark,

MediaWiki is the underlying software of Wikipedia. It is open source software licensed under the GPL. It is written in PHP and (I think) requires a MySQL database. It's fairly easy to set up, widely supported and straight forward to use.

CU
Froestel

Hi Abiodun Adisa,

in general this should not be that hard: retrieve the item from the database, copy its values to a new instance, delete the old instance (esp. in the DB) and then save the new one.

But before you go on, you should probably rethink your design. This operation you are trying to accomplish is not straight forward because it is bad style. You should never be in need to change a primary key. This will usually lead to inconsistent data if the database does not keep track - and will cause you a lot of trouble if the database keeps track.

Use a surrogate primary key and put a UNIQUE constraint on your triplet of entries. This is much better and easier to handle.

CU
Froestel

Hi Angel,

Angel Mendoza wrote:Thanks Andreas,

That was the problem, hehe!

Wow, what a coincidence, working right in parallel - sorry, man, I recognized afterwards that you already figured it out.

CU
Froestel

Hi Angel,

have you tried to specify the associated class appropriately? Try one of the following two options:

1) see the modified <many-to-many>-element
<?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping> ... <set name="menus" inverse="true" table="menuxrol"> <key> <column name="rolid" length="10" not-null="true" /> </key> <many-to-many column="menuid" class="modelo.Menu"/> </set> </class> </hibernate-mapping>

2) see the modified <hibernate-mapping> and the <class> element
<?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping package="modelo"> <class name="Rol" table="rol" catalog="gastos01"> ... <set name="menus" inverse="true" table="menuxrol"> <key> <column name="rolid" length="10" not-null="true" /> </key> <many-to-many column="menuid" class="Menu"/> </set> </class> </hibernate-mapping>

CU
Froestel

Btw: Make heavy use of the BBCode buttons atop of the subject field. It's much easier to read your postings then, esp. the code snippets.

Hi again,

just figured out, that the whole thing comes down to using the entity name. If I explicitly enter the fully qualified name in the @Entity annotation like
@Entity(name="fully.qualified.name.for.Entity")
the query works fine. But if I had to do this, using content based discrimination does not make any sense since I could use @DiscriminatorValue...

Is there a way to globally configure Hibernate to use the fully qualified name of an entity by default?

CU
Froestel

Hi folks,

I am curious on an issue pertaining content based discrimination with Hibernate annotations.

I've set up my entities with annotations. From an abstract base class using single table inheritance, a couple of sub-classes add some fields and use a secondary table for storing their data. Each of these sub-classes is furthermore extended by (sub-)sub-classes that simply have a different type name but do not add any new fields or so.

To distinguish the different types I use content based discrimination based upon a field type of Java type Class<?>. For being able to use type-safe polymorphic queries I set up an interface for each entity class to be used as a proxy generator.

Here is some example code:
@Entity(name = "topentity") @Proxy(proxyClass = ITopEntity.class) @Inheritance(strategy = InheritanceType.SINGLE_TABLE) @DiscriminatorFormula("CASE WHEN type IS NULL THEN 'fully.qualified.pathname.to.TopEntity' ELSE type END") abstract class TopEntity implements ITopEntity { ... private Class<?> type; ... } // sub-class example @Entity @Proxy(proxyClass = ISubEntity.class) @SecondaryTable(name = "subentitya", pkJoinColumns = { @PrimaryKeyJoinColumn(name = "id", referencedColumnName = "id") }) @ForeignKey(name = "FK_SubEntity_TopEntity") public abstract class SubEntity extends TopEntity implements ISubEntity { ... } // sub-sub-class example @Entity @Proxy(proxyClass = ISubSubEntity.class) public abstract class SubSubEntity extends SubEntity implements ISubSubEntity { ... }

This works perfectly fine when using a mapping file like this:
<hibernate-mapping ...> <class name="TopEntity" table="topentity" abstract="true" ... > ... <discriminator formula="CASE WHEN type IS NULL THEN 'fully.qualified.pathname.to.TopEntity' ELSE type END" /> ... <subclass name="SubEntity" extends="TopEntity" proxy="ISubEntity"> <join table="subentity"> ... </join> </subclass> ... <subclass name="SubSubEntity" extends="SubEntity" proxy="ISubSubEntity"> </subclass> ... </hibernate-mapping>

But for some reasons I (think I) need to switch to annotations. Unfortunately, it does not work as expected anymore and the problem is at a place where I don't feel I could do anything about it.

The content-based discrimination works perfectly (with annotations) when inserting items of different types. I end up having the discriminator column (i.e., topentity.type) filled with the fully qualified class names as expected. When I issue polymorphic queries (polymorphism by default implicit) on the entities the result is always empty since the query contains the simple class names only instead of the fully qualified ones.

Did anyone ran into this issue already?
Is there a solution?

Thanks in advance for replies.

CU
Froestel

Hi Natt,

Natt Gonzalez wrote:Hi! I'm new using Hibernate and I want to make this query in hibernate:
select count(*) from (select ID from myTable where fieldId =196135 group by ID)
...

I don't really think I get what you intend to do...

What do you actually want to count? It looks like you want to count all entries of myTable having fieldId =196135, since I suppose the field ID is unique, actually a PK. So why not use
SELECT count(*) FROM myTable WHERE fieldId=196135
??? Or did I miss something?

CU
Froestel

Hi Ally Cavs,

you shouldn't worry too much about IDs. Usually these are surrogate keys with no meaning to the application. Except when loading an object by ID you hardly get in touch with it.

Let your Chapter class reference a Book instance but not the book ID. Hibernate will take care of the rest.

CU
Froestel

Hi John Landon,

the Session.get() method returns an uninitialized proxy of the requested entity. To not cause a LazyInitializationException you could "touch" the proxy within the session by deliberately calling one of its methods which forces proxy initialization. You could also choose Session.load() which returns an initialized instance.

CU
Froestel

Hi Tony Crisera,

your collection is mapped inverse so both ends "know" of the collection. There should be no problem if you save (or delete) your children without touching the parent - as long as you have a reference to the parent in your child instance. You should also be able to see this from your DB schema. I'd expect that your child table has a FK column referencing the parent table whereas the parent table does not show any sign of "knowledge" about the child table.

On your original issue with the collection fetching. This might be dependent on the kind of collection you choose. I could imagine a HashSet has to be loaded completely in order to decide if the child is actually to be added or not. For each existing entry the hashCode must be calculated to check if the new item is actually a duplicate (will not add) or not (will add).

CU
Froestel

Hi Kim Kantola,

I've never used named queries myself but my first guess is if you want to use a wildcard you should probably try the SQL-wildcard of your DBMS. That is, most likely, the per-cent sign "%".

CU
Froestel

Hi John Landon,

ok, I try a second time... hm, what about cascading? Could there be conflicts when cascading your delete to associations? Probably over several stages?

CU
Froestel

Hi Nrapendra Sharma,

it would possibly be the same as in SQL, use a count() query on each of your fields in question. Something like
session.createCriteria(YourEntityClass.class) .setProjection( Projections.projectionList() .add(Projections.groupProperty("yourPropertyName")) .add(Projections.rowCount()) ) ) .list();I haven't tested this code, not even syntax checked.

This should give you a two column result set with the first column providing the value and the second the count how often it occurs.
I'd suggest a single query for each of the fields - otherwise it gets rather complicated.

CU
Froestel

Hi Shariquddin Mohammed,

this might be an issue with the name of your MachineDetails.NIC_IP field and its accessor methods. Hibernate might have either problems with the all capital letters of the name or with the underscore. If it is no problem for your app then stick to the Java (Beans) naming conventions, i.e. use CamelCaseNotation, starting with a lower case letter for field names, and the getter/setter methods start with get/set followed by the field name now having the first letter capitalized. Might make things easier.

CU
Froestel