Ok, I've figured out what exactly is causing it and how to work around
it. I can't say why, but perhaps a resident hibernate guru will know (it
may even be a know issue or gotcha). First off, the quick fix. This
query (and variations like load(), get(), and using the criteria api)
cause the problem:

        Listing listing = (Listing)session.createQuery("from Listing lst
where lst.id=:id")
            .setLong("id", Long.valueOf(sListingId)).uniqueResult();

This works as expected:

        Listing listing = (Listing)session.createQuery("from Listing lst
where lst.id=" + sListingId)
            .uniqueResult();

It seems to come down to how hibernate handles the query results when
the query is formed with a "raw" HQL string vs something like get(),
load(), the criteria api, or using query parameters as I was initially
doing. It also has something to do with the field being queried and
seems to happen only on fields that exist in each of the tables. In my
case the abstract super class Listing has the PK field "id", and the 2
subclasses also have a PK field named "id." Querying by any method other
than "constructed strings" leads to the issue, while querying on another
field in the super class, whose name is unique to that class, works fine.

So the BIG question is why in the world does it work the first time and
continue to work until the value one queries by changes?

I'd also like to know if anyone has seen this before, and/or if it's a
known issue. I'm using a slightly outdated version of hibernate
(3.2.2.ga) and for all I know this may be fixed in more recent versions.
My wrists are shot so I'll try tomorrow. If anyone knows of this or gets
interested/bored enough to try it, please let me know.

Thanks tons for all of your input.

Sincerely,
Chris Lewis

Chris Lewis wrote:
> Hello,
>
> I have a dispatcher that uses a hibernate session. The dispatcher is
> auto bound and receives the session in the constructor. I'm using
> tapestry-hibernate so that session instance is a proxy that gets the
> real session for the current thread (right?). Now in testing my
> dispatcher, I give it a url like:
>
> /MyContext/?limg=2
>
> The dispatcher looks for "limg" and if found, queries the session
> assuming that its value is the PK of a mapped entity. When I trigger the
> dispatcher for the first time it works fine. If I refresh the page,
> fine. If I change the value to something else, say 3, then it breaks
> with a org.hibernate.InstantiationException:
>
> Cannot instantiate abstract class or interface: com.mypackage.data.Listing
>
> If I change the value back to 2, the same thing happens! "Listing" is an
> abstract class mapped as a super class entity via:
>
> @Entity
> @Inheritance(strategy = InheritanceType.JOINED)
>
> Any clue what's going on here? Two things are perplexing me:
>
> 1) Querying mapped super classes is legal, and I in fact the same thing
> on my Index page with no problem.
> 2) The query works the first time, but as soon as the id changes it is
> forever broken until I restart the container.
>
> Thanks in advance!
>
> chris
>
>   

-- 
http://thegodcode.net


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to