unfortunately you are correct (I wrote that code) with the dependent objects and the join to load them all, the absolute, .size and .relative are all "random"
unfortunately, there is no "easy" way to solve this: 1. Change the way Castor loads dependent objects (2 queries) (solves all .size, .relative and .absolute issues) 2. Change the .size, .absolute, and .relative to iterate through all objects (UGGGGG) (solves all .size, .relative and .absolute issues) 3. Change the .size to execute the appropriate count(*) (solves only the the .size problem) Maybe there is another way I'm not familiar with. I would recommend going with 1, as it is the best from a performance point of view, otherwise there really isn't a reason to put this functionality into castor, just have it in your app. m -----Original Message----- From: Mickaël Guessant [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 11:10 AM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Problem with absolute/size on QueryResults Hi, Your description is absolutely right... If you have a look at the size() code in OQLQueryImpl : public int size() throws PersistenceException { return _results.size(); } you can see that the returned value is just the ResultSet size. Unfortunately, I don't see any easy way to count the actual number of master objects : we would have to iterate over all the results. Paul Danckaert wrote: > Greetings, > > I was testing the absolute positioning on QueryResults in conjunction > with the size, and found the results to be rather interesting. What > appears to be happening is that when you have a parent/child dependent > object relationship, the size and the positioning reflect the SQL > JOIN'ed query results rather than the parent object results, even though > you are iterating over just the parent object in the results. > > As an example, if I have a Master object that contains one or more > Detail dependent objects in the following configuration: > > master id1 has detail dt1,dt2,dt3 > master id2 has detail dt4,dt5,dt6 > > My join'ed query results look something like: > > id1 | dt1 > id1 | dt2 > id1 | dt3 > id2 | dt4 > id2 | dt5 > id2 | dt6 > > In this situation, my straight SQL result set size is 6, but my count of > Master objects should be 2. So, in a OQL query like: > > SELECT master from test.Master > > Should I expect to get a size of 6 or 2? I get 6, but I would expect to > get 2, as there are actually only two items in the results. (If you > perform the actual iteration with .hasMore() and .next() you will only > get two objects back.) > > I believe that if I removed the depenent object mapping, I would > probably get the correct size, since we wouldn't have the JOIN confusing > the row count. > > Extending this problem, if we then look at calling absolute on the > QueryResult's, it gets pretty interesting. The absolute call positions > itself into the results above, which means your absolute position is > fairly random, and you can actually absolute position yourself from 1 to > 6, as opposed to from 1 to 2. > > So, what should the expected behavior be of size and absolute? I didn't > read anything in the API reference about it being limited to simple > objects without relationships, but that seems to be the behavior that > I'm seeing. Its certainly possible I'm doing this wrong, so I would be > glad to hear of it working properly in this situation. I'm running > against a Postgres database, using both the postgres supplied drivers as > well as the castor supplied drivers. I'm also using Castor 0.9.4.1. > > I have tested a straight JDBC query and iteration, and absolute works > the way its expected to. In fact, absolute does work in the castor > test, but its absolute referenced into the joined results, which makes > it a pretty confusing set to iterate through. > > Thanks for any help on this, > > paul > > > > pgsq/0941 > > -- Mickael Guessant ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
