Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #33214

Re: Using GROUP By or @OrderColumn in JPA

Show all headers | View raw

On 11/27/2015 6:28 AM, Silvio wrote:
> On 11/27/2015 02:22 AM, Arne Vajhøj wrote:
>> On 11/26/2015 1:28 AM, Cecil Westerhof wrote:
>>> On Thursday 26 Nov 2015 02:02 CET, Arne Vajhøj wrote:
>>>> On 11/25/2015 3:07 AM, Cecil Westerhof wrote:
>>>>> We are working on our first project with JPA. We had some bumps in
>>>>> the road, but I find it a good tool.
>>>>>
>>>>> We have an entity request which has a one to many relationship with
>>>>> estimate which has a one to one relationship with decision. One of
>>>>> the fields of decision is date.
>>>>>
>>>>> We need request-estimate-decision's where the date field of
>>>>> decision is not null and has the highest value. (We are only
>>>>> interested in the latest decision pro request.)
>>>>>
>>>>> I was thinking about a GROUP BY, but someone else thought about
>>>>> @OrderColumn. But if I understand it correctly an @OrderColumn
>>>>> needs an Integer and an index. We cannot change the database
>>>>> definition. So I suppose that @OrderColumn is not an option and we
>>>>> need to use the GROUP BY?
>>>>
>>>> How did you do it before with SQL?
>>>
>>> This was never done with SQL. They made a JPQL query that was badly
>>> written. I managed to help rewrite it, so it is a bit clearer what is
>>> happening. But everything was done over instant message, which is not
>>> ideal. Today we will meet face to face and I hope to get a better
>>> understanding of what they want and have.
>>
>> I would probably do one of these:
>>
>> 1) Let JPA retrieve all decisions but add a getLastDecision
>>     method to the Estimate class. If the number of decisions
>>     per estimate is small then the overhead should be
>>     insignificant.
>>
>> 2) Don't let JPA map between estimates and decisions. Instead
>>     make a getLastDecision method in Estimate class that
>>     does a separate JPQL query to get the data. If the number
>>     of estimate for which you need last decision is small
>>     then the overhead should be insignificant.
>>
>> Yes - I am arguing for a very simple solution. Unless you
>> really have a performance problem that requires a complex
>> solution then I strongly believe in keeping it simple.
>>
>> Arne
>>
>>
>>
>>
> 
> I usually agree on keeping things as simple as possible given the
> circumstances. But I would be very hesitant to give this as general
> advice to someone who is in a situation I do not know.
> 
> I spoke of performance problems in ORM based applications here before.
> Most of these where caused by an accumulation of many "keep it simple"
> solutions.
> 
> Sometimes the data had just outgrown the simple solution and the sheer
> volume demanded a more optimal solution.
> 
> In other cases each little simple solution seemed to do just fine but a
> user action could result in tens of such simple actions being performed.
> A database action that takes 0.2 second seems plausible and hardly
> problematic. But use cases where consistently ~30 such actions will be
> performed result in a six second hick-up.
> 
> It's a very thin line between premature optimization and technical debt.
> Only if you can reliably predict both the volume of the data and the use
> case scenarios can one decide how many effort should be spent optimizing
> things.
> 
> Waiting for performance problems to happen in production before
> optimizing may be acceptable in some situations but you can not afford
> to take this approach system wide.
> 
> Only Cecil can decide here.
> 

Part of good programming is performance testing - that is, testing under
a typical load you would see in real life.  This includes the number of
concurrent users, database size, typical operations, hardware being
used, etc.  Good testing will show performance problems.

Just testing with one user and a minimal database is like an automobile
manufacturer building a car and just testing it at 5mph in a large,
empty parking lot.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Using GROUP By or @OrderColumn in JPA Cecil Westerhof <Cecil@decebal.nl> - 2015-11-25 09:07 +0100
  Re: Using GROUP By or @OrderColumn in JPA Arne Vajhøj <arne@vajhoej.dk> - 2015-11-25 20:02 -0500
    Re: Using GROUP By or @OrderColumn in JPA Cecil Westerhof <Cecil@decebal.nl> - 2015-11-26 07:28 +0100
      Re: Using GROUP By or @OrderColumn in JPA Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-26 08:25 -0500
      Re: Using GROUP By or @OrderColumn in JPA Arne Vajhøj <arne@vajhoej.dk> - 2015-11-26 20:22 -0500
        Re: Using GROUP By or @OrderColumn in JPA Silvio <silvio@internet.com> - 2015-11-27 12:28 +0100
          Re: Using GROUP By or @OrderColumn in JPA Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-27 09:22 -0500
            Re: Using GROUP By or @OrderColumn in JPA Silvio <silvio@internet.com> - 2015-11-27 17:42 +0100
              Re: Using GROUP By or @OrderColumn in JPA Silvio <silvio@internet.com> - 2015-11-27 17:43 +0100
                Re: Using GROUP By or @OrderColumn in JPA Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-27 18:21 +0000
          Re: Using GROUP By or @OrderColumn in JPA Arne Vajhøj <arne@vajhoej.dk> - 2015-11-28 23:01 -0500
            Re: Using GROUP By or @OrderColumn in JPA Silvio <silvio@internet.com> - 2015-11-29 12:42 +0100
        Re: Using GROUP By or @OrderColumn in JPA Arne Vajhøj <arne@vajhoej.dk> - 2015-11-28 22:44 -0500
      Re: Using GROUP By or @OrderColumn in JPA Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-27 11:07 +0000

csiph-web