Making listing non-abstract "offends my sensibilities" but I occasionally need to offend myself.
1) I've actually never tried. I did run into problems when joining two hierarchies via a third relationship hierarchy. (Take two classes related by an association where there are additional properties on the relation - making it a class. Now subclass everything.) Hibernate worked inconsistently as well. I didn't delve far enough to elicit a pattern, but it might be related. 2) Strange, I know. The inconsistency I experienced was in a T5 project, but I was executing it in a command-line utility class with Spring for wiring things together. I don't think your problem is T5-specific. 3) I've never had a problem with objects fetched via associations. As a test, is there an association you can leverage? Like "select au, li from Author au join au.listings li where li.id = ?" Then just ignore Author or whatever else you fetch? Perhaps a guru on the Hibernate list can help. > -----Original Message----- > From: Chris Lewis [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 24, 2008 17:43 > To: Tapestry users > Subject: Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a > Session > > I don't want to change Listing to be non-abstract, but I did try > querying a concrete subclass and that doesn't suffer from the same > defect. So that raises/reiterates a few questions > > 1) Can't you, via HQL, query an interface or abstract class entity with > the goal of getting a collection of all objects in a class hierarchy, > where the actual instantiated types are correctly resolved by hibernate? > > 2) Why in the world does this work if I query one specific entity - even > subsequent requests for the same one - until I query a different one at > which point it is permanently broken? > > 3) Even though I'm not having this in my page class where I need all of > the varying subclass entity instances in a single collection, should I > be worried? I imagine the answer to #1 will answer this. > > I haven't verified that this happens in a non-T5 context, but I'll test > that later and share my findings. > > chris > > Jonathan Barker wrote: > > Be paranoid. Set hibernate.show_sql=true. Grab the SQL statement, and > > execute it manually. > > > > Also, can you change Listing to be non-abstract - even if you never use > it? > > > > > > > > > >> -----Original Message----- > >> From: Chris Lewis [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, July 24, 2008 15:41 > >> To: Tapestry users > >> Subject: Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a > >> Session > >> > >> I haven't looked at the source of hibernate (or read) to see what > >> exactly goes on, but the erratic behavior of load() is precisely the > >> same as this: > >> > >> Listing listing = (Listing)session.createQuery("from Listing > >> where id=:id") > >> .setLong("id", Long.parseLong(sListingId)).uniqueResult(); > >> > >> I just replaced the load() call with this, so now the source is: > >> > >> public class BinaryFileDispatcher implements Dispatcher { > >> > >> private Session session; > >> > >> public BinaryFileDispatcher(Session session) { > >> this.session = session; > >> } > >> > >> public boolean dispatch(Request request, Response response) > >> throws IOException { > >> > >> String sListingId = request.getParameter("limg"); > >> if(sListingId== null) > >> return false; > >> > >> System.out.println("BinaryFileDispatcher.dispatch() -- " + > >> sListingId); > >> > >> Listing listing = (Listing)session.createQuery("from Listing > >> where id=:id") > >> .setLong("id", Long.parseLong(sListingId)).uniqueResult(); > >> > >> response.setHeader("Content-Type", "text/html"); > >> > >> String test = "<html><body><h1>" + listing.getTitle() + > >> "</h1></body></html>"; > >> response.setContentLength(test.length()); > >> PrintWriter writer = response.getPrintWriter("text/html"); > >> writer.append(test).flush(); > >> return true; > >> } > >> > >> } > >> > >> > >> Quick summary of the behavior with the following urls: > >> > >> 1) request /LStAug/?limg=1 > >> works > >> > >> 2) request /LStAug/?limg=1 (again) > >> works > >> > >> 3) request /LStAug/?limg=2 > >> breaks > >> > >> 4) request /LStAug/?limg=1 > >> breaks, where it worked before > >> > >> (restart container) > >> > >> 1) request /LStAug/?limg=2 > >> works > >> > >> 2) request /LStAug/?limg=1 > >> breaks > >> > >> 3) request /LStAug/?limg=2 > >> breaks > >> > >> so strange. > >> > >> > >> Jonathan Barker wrote: > >> > >>> I'm not sure why it WORKED. > >>> > >>> Session.load will try to create an instance of Listing, which it can't > >>> because it is abstract. > >>> > >>> On the other hand, if you do a query, then even though you ask for a > >>> Listing, Hibernate will look for any descendant of Listing. > >>> > >>> The actual object type returned will depend on the actual type for any > >>> instance found. You can then cast to Listing without a problem. > >>> > >>> Get rid of load(). > >>> > >>> Jonathan > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Chris Lewis [mailto:[EMAIL PROTECTED] > >>>> Sent: Thursday, July 24, 2008 14:37 > >>>> To: Tapestry users > >>>> Subject: Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using > a > >>>> Session > >>>> > >>>> Hi Jonathan, > >>>> > >>>> Here is my dispatcher. As you can see it's in a very early stage so > >>>> > >> it's > >> > >>>> both small and messy. The query is being done via: > >>>> session.load(Listing.class, Long.parseLong(sListingId)); > >>>> > >>>> It was being done via createQuery and uniqueResult, with the same > >>>> > >> results. > >> > >>>> public class BinaryFileDispatcher implements Dispatcher { > >>>> > >>>> private Session session; > >>>> > >>>> public BinaryFileDispatcher(Session session) { > >>>> this.session = session; > >>>> } > >>>> > >>>> public boolean dispatch(Request request, Response response) > >>>> throws IOException { > >>>> > >>>> String sListingId = request.getParameter("limg"); > >>>> if(sListingId== null) > >>>> return false; > >>>> > >>>> System.out.println("BinaryFileDispatcher.dispatch() - > - > >>>> > >> " > >> > >>>> + sListingId); > >>>> Listing listing = > (Listing)session.load(Listing.class, > >>>> Long.parseLong(sListingId)); > >>>> > >>>> response.setHeader("Content-Type", "text/html"); > >>>> > >>>> String test = "<html><body><h1>" + listing.getTitle() > + > >>>> "</h1></body></html>"; > >>>> response.setContentLength(test.length()); > >>>> > >>>> > >> response.getPrintWriter("text/html").append(test).flush(); > >> > >>>> return true; > >>>> } > >>>> > >>>> } > >>>> > >>>> > >>>> Jonathan Barker wrote: > >>>> > >>>> > >>>>> Post your query and load code. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Chris Lewis [mailto:[EMAIL PROTECTED] > >>>>>> Sent: Thursday, July 24, 2008 13:16 > >>>>>> To: Tapestry users > >>>>>> Subject: Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when > using > >>>>>> > >> a > >> > >>>>>> Session > >>>>>> > >>>>>> It can't be a data issue. The records are persisted via hibernate > and > >>>>>> work consistently as expected in pages. Like I said, I query the > same > >>>>>> table to which the abstract class is mapped in my index page with > no > >>>>>> problem at all. I also said that it works in the dispatcher for the > >>>>>> first entity I query, but any subsequent query to a _different_ > >>>>>> > >> entity > >> > >>>>>> throws that exception. The query is also just a read (select). Any > >>>>>> > >>>>>> > >>>> other > >>>> > >>>> > >>>>>> ideas? > >>>>>> > >>>>>> thanks > >>>>>> > >>>>>> Yunhua Sang wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> It sounds more like a data issue, check your data in database > >>>>>>> > >>>>>>> > >>>> carefully. > >>>> > >>>> > >>>>>>> Yunhua > >>>>>>> > >>>>>>> On Wed, Jul 23, 2008 at 11:18 PM, Chris Lewis > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> <[EMAIL PROTECTED]> 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] > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> ------------------------------------------------------------------ > -- > >>>>>>> > >> - > >> > >>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> -- > >>>>>> http://thegodcode.net > >>>>>> > >>>>>> > >>>>>> > >>>>> -------------------------------------------------------------------- > - > >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> -- > >>>> http://thegodcode.net > >>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >> -- > >> http://thegodcode.net > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > http://thegodcode.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
