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

Groups > comp.lang.java.programmer > #37132 > unrolled thread

Where to put the return

Back to article view | Back to comp.lang.java.programmer

Contents

  Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-11 10:30 +0200
    Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-11 12:24 +0200
    Re: Where to put the return Eric Douglas <e.d.programmer@gmail.com> - 2017-08-11 08:31 -0700
    Re: Where to put the return Arne Vajhøj <arne@vajhoej.dk> - 2017-08-11 20:33 -0400
      Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-13 00:27 +0200
        Re: Where to put the return Arne Vajhøj <arne@vajhoej.dk> - 2017-08-12 21:41 -0400
          Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-13 13:15 +0200
        Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-15 08:12 +0200
          Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-19 11:10 +0200
            Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-19 12:54 +0200
              Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-19 13:46 +0200
                Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-19 14:10 +0200
                Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-19 15:35 +0200
                  Re: Where to put the return Arne Vajhøj <arne@vajhoej.dk> - 2017-08-19 09:48 -0400
                    Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-19 23:26 +0200
                      Re: Where to put the return Arne Vajhøj <arne@vajhoej.dk> - 2017-08-19 20:01 -0400
                        Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-20 19:30 +0200
                  Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-19 17:06 +0200
              Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-19 15:35 +0200
                Re: Where to put the return Arne Vajhøj <arne@vajhoej.dk> - 2017-08-19 09:43 -0400
                Re: Where to put the return Cecil Westerhof <Cecil@decebal.nl> - 2017-08-19 17:15 +0200
                  Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-21 22:33 +0200
            Re: Where to put the return lewbloch@gmail.com - 2017-08-19 09:20 -0700
              Re: Where to put the return Robert Klemme <shortcutter@googlemail.com> - 2017-08-21 22:29 +0200
      Re: Where to put the return Eric Douglas <e.d.programmer@gmail.com> - 2017-08-14 05:11 -0700
    Re: Where to put the return Brixomatic <brixomatic@yahoo.com> - 2017-08-31 19:27 +0200

Page 1 of 2  [1] 2  Next page →

#37132 — Where to put the return

I have the following function:
    private static String getOldestUsed() {
        String oldestUsed = "";

        try (Statement stmt     = sqlite3Conn.createStatement();
             ResultSet rsOldest = stmt.executeQuery(OLDEST_USED)) {
            if (rsOldest.next()) {
                oldestUsed = rsOldest.getString("used");
            }
        } catch (SQLException e) {
            giveError("Error in displayOldestUsed");
            e.printStackTrace();
            fatalError("");
        }
        return oldestUsed;
    }

Often I see the return in the try block. But personally I prefer it
this way. Is there a preferred way, or are both ways acceptable?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#37134

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Cecil Westerhof <Cecil@decebal.nl> writes:
>>Often I see the return in the try block. But personally I prefer it
>>this way. Is there a preferred way, or are both ways acceptable?
>
>   It might just be a question of being compilable.
>
>   For example, in the following case, I get a compile-time error:
>
> Main.java
>
> public final class Main 
> { 
>   public static int f() 
>   { try( final java.util.Scanner scanner = new java.util.Scanner( "" ))
>     { return 1; }
>     catch( final java.lang.RuntimeException exception )
>     {} }
>
>   public static void main( final java.lang.String[] args ) 
>   { java.lang.System.out.println( f() ); }}
>
> transcript
>
> Main.java: error: missing return statement
>     {} }
>        ^
> 1 error
>
>   The compile-time error disappears once the catch clause
>   is removed or the return is moved to the end of the method.

Yes, the examples I saw did not use a catch clause.

Well, if there is no reason not to move the return out of the try
block, I will keep doing that.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#37135

On Friday, August 11, 2017 at 4:44:19 AM UTC-4, Cecil Westerhof wrote:
> I have the following function:
>     private static String getOldestUsed() {
>         String oldestUsed = "";
> 
>         try (Statement stmt     = sqlite3Conn.createStatement();
>              ResultSet rsOldest = stmt.executeQuery(OLDEST_USED)) {
>             if (rsOldest.next()) {
>                 oldestUsed = rsOldest.getString("used");
>             }
>         } catch (SQLException e) {
>             giveError("Error in displayOldestUsed");
>             e.printStackTrace();
>             fatalError("");
>         }
>         return oldestUsed;
>     }
> 
> Often I see the return in the try block. But personally I prefer it
> this way. Is there a preferred way, or are both ways acceptable?
> 

It depends what you're trying to return.  If you do it like that, declare a simple variable to be returned before the try block, there's no reason the return needs to be in the try block.  If you have a method which could throw an error as the parameter to the return then of course it needs to be in a try block.  If the return is after the try block you need to know if it's acceptable to return a value if the method catches an exception.  If not, you need to remember to throw something in the catch clause regardless.  It should compile with the return in the try block as long as there is a return or throw in the catch clause, or after the try block which would work the same as putting it in the catch clause unless the return in the try block is in a conditional statement.

[toc] | [prev] | [next] | [standalone]

#37137

On 8/11/2017 4:30 AM, Cecil Westerhof wrote:
> I have the following function:
>      private static String getOldestUsed() {
>          String oldestUsed = "";
> 
>          try (Statement stmt     = sqlite3Conn.createStatement();
>               ResultSet rsOldest = stmt.executeQuery(OLDEST_USED)) {
>              if (rsOldest.next()) {
>                  oldestUsed = rsOldest.getString("used");
>              }
>          } catch (SQLException e) {
>              giveError("Error in displayOldestUsed");
>              e.printStackTrace();
>              fatalError("");
>          }
>          return oldestUsed;
>      }
> 
> Often I see the return in the try block. But personally I prefer it
> this way. Is there a preferred way, or are both ways acceptable?

I would go for:

       private static final String NO_VALUE = "";
       private static String getOldestUsed() {
           try (Statement stmt     = sqlite3Conn.createStatement();
               ResultSet rsOldest = stmt.executeQuery(OLDEST_USED)) {
               if (rsOldest.next()) {
                   return rsOldest.getString("used");
               } else {
                   return NO_VALUE;
	      }
           } catch (SQLException e) {
               giveError("Error in displayOldestUsed");
               e.printStackTrace();
               fatalError("");
               return NO_VALUE;
           }
       }

But there are many acceptable ways of writing this.

Arne

[toc] | [prev] | [next] | [standalone]

#37154

On 12.08.2017 02:33, Arne Vajhøj wrote:

> I would go for:
> 
>        private static final String NO_VALUE = "";
>        private static String getOldestUsed() {
>            try (Statement stmt     = sqlite3Conn.createStatement();
>                ResultSet rsOldest = stmt.executeQuery(OLDEST_USED)) {
>                if (rsOldest.next()) {
>                    return rsOldest.getString("used");
>                } else {
>                    return NO_VALUE;
>                }
>            } catch (SQLException e) {
>                giveError("Error in displayOldestUsed");
>                e.printStackTrace();
>                fatalError("");
>                return NO_VALUE;
>            }
>        }
> 
> But there are many acceptable ways of writing this.

Your approach has a few advantages though:

  - The compiler will catch the case that you forget to include
    an explicit return in the catch.
  - For the reader the code for the regular case (i.e. without
    exception) is in one place (in the try body) so it is easier
    to digest.

Btw. I'd rather throw in catch than return a special value.  That is 
cleaner and does not break if the special value actually occurs in the 
database.

And another remark: we do not see the SQL but in this case I would make 
sure that OLDEST_USED actually returns exactly one column and access 
that via index instead of name.  IIRC this tends to be slightly quicker. 
  But it may be just an old habit of mine.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#37156

On 8/12/2017 6:27 PM, Robert Klemme wrote:
> On 12.08.2017 02:33, Arne Vajhøj wrote:
>> I would go for:
>>
>>        private static final String NO_VALUE = "";
>>        private static String getOldestUsed() {
>>            try (Statement stmt     = sqlite3Conn.createStatement();
>>                ResultSet rsOldest = stmt.executeQuery(OLDEST_USED)) {
>>                if (rsOldest.next()) {
>>                    return rsOldest.getString("used");
>>                } else {
>>                    return NO_VALUE;
>>                }
>>            } catch (SQLException e) {
>>                giveError("Error in displayOldestUsed");
>>                e.printStackTrace();
>>                fatalError("");
>>                return NO_VALUE;
>>            }
>>        }
>>
>> But there are many acceptable ways of writing this.
> 
> Your approach has a few advantages though:
> 
>   - The compiler will catch the case that you forget to include
>     an explicit return in the catch.
>   - For the reader the code for the regular case (i.e. without
>     exception) is in one place (in the try body) so it is easier
>     to digest.
> 
> Btw. I'd rather throw in catch than return a special value.  That is 
> cleaner and does not break if the special value actually occurs in the 
> database.

Yes.

Exception instead of "magic value" is better if possible.

Arne

[toc] | [prev] | [next] | [standalone]

#37174

On 13.08.2017 03:41, Arne Vajhøj wrote:
> On 8/12/2017 6:27 PM, Robert Klemme wrote:
>> On 12.08.2017 02:33, Arne Vajhøj wrote:
>>> I would go for:
>>>
>>>        private static final String NO_VALUE = "";
>>>        private static String getOldestUsed() {
>>>            try (Statement stmt     = sqlite3Conn.createStatement();
>>>                ResultSet rsOldest = stmt.executeQuery(OLDEST_USED)) {
>>>                if (rsOldest.next()) {
>>>                    return rsOldest.getString("used");
>>>                } else {
>>>                    return NO_VALUE;
>>>                }
>>>            } catch (SQLException e) {
>>>                giveError("Error in displayOldestUsed");
>>>                e.printStackTrace();
>>>                fatalError("");
>>>                return NO_VALUE;
>>>            }
>>>        }
>>>
>>> But there are many acceptable ways of writing this.
>>
>> Your approach has a few advantages though:
>>
>>   - The compiler will catch the case that you forget to include
>>     an explicit return in the catch.
>>   - For the reader the code for the regular case (i.e. without
>>     exception) is in one place (in the try body) so it is easier
>>     to digest.
>>
>> Btw. I'd rather throw in catch than return a special value.  That is 
>> cleaner and does not break if the special value actually occurs in the 
>> database.
> 
> Yes.
> 
> Exception instead of "magic value" is better if possible.

One more thing: since you used the same "magic value" for "exception" 
and "not found" caller cannot distinguish.  Whether that is an issue 
depends of course on the other logic.  Just wanted to point that out.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#37229

Robert Klemme <shortcutter@googlemail.com> writes:

> Btw. I'd rather throw in catch than return a special value.  That is
> cleaner and does not break if the special value actually occurs in the
> database.

I agree. But that is what the call to fatalError does: it cleans up
resources and exits the program. But I changed that to just let the
SQLException fire:
    private static String getOldestUsed() throws SQLException {
        String oldestUsed = "";

        try (SQLResultSet rsOldest = sqlite3Conn.executeQuery(OLDEST_USED)) {
            if (rsOldest.next()) {
                oldestUsed = rsOldest.getString("used");
            }
        }
        return oldestUsed;
    }


> And another remark: we do not see the SQL but in this case I would make
> sure that OLDEST_USED actually returns exactly one column and access
> that via index instead of name.  IIRC this tends to be slightly quicker.
> But it may be just an old habit of mine.

One of the things I do is make sure you cannot use index. I find that
a very bad habit. Also when you give the wrong query, but it gives one
column back, you have a hard to find bug.

The SQL used:
    SELECT used
    FROM   usedProverbs
    LIMIT  1

I defined usedProverbs as a sorted view (on proverbs), that is why
there is no SORT BY.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#37280

On 15.08.2017 08:12, Cecil Westerhof wrote:
> Robert Klemme <shortcutter@googlemail.com> writes:
> 
>> Btw. I'd rather throw in catch than return a special value.  That is
>> cleaner and does not break if the special value actually occurs in the
>> database.
> 
> I agree. But that is what the call to fatalError does: it cleans up
> resources and exits the program. But I changed that to just let the
> SQLException fire:
>      private static String getOldestUsed() throws SQLException {
>          String oldestUsed = "";
> 
>          try (SQLResultSet rsOldest = sqlite3Conn.executeQuery(OLDEST_USED)) {
>              if (rsOldest.next()) {
>                  oldestUsed = rsOldest.getString("used");
>              }
>          }
>          return oldestUsed;
>      }

I'd rather

private static String getOldestUsed() throws SQLException {
     try (final SQLResultSet rs = sqlite3Conn.executeQuery(OLDEST_USED)) {
         if (rs.next()) {
             return rs.getString("used");
         }
     }

     return "";
}


But religious wars have been fought about additional returns inside 
methods.  To me this reads easier because you see the fallback return 
value immediately and you can recognize immediately what value is 
returned.  In this smallish example it probably does not make a 
difference though.

Btw. SQL statements when used like this tend to be specific to the 
method.  So by inserting the SQL directly in the method instead of in a 
constant the reader has more information at hand and can quicker 
understand the logic.  Constants make much more more sense if the SQL is 
actually reused in different locations.

>> And another remark: we do not see the SQL but in this case I would make
>> sure that OLDEST_USED actually returns exactly one column and access
>> that via index instead of name.  IIRC this tends to be slightly quicker.
>> But it may be just an old habit of mine.
> 
> One of the things I do is make sure you cannot use index. I find that
> a very bad habit.

Why?

> Also when you give the wrong query, but it gives one
> column back, you have a hard to find bug.

If the value happens to be of the same type as the expected one, yes. 
But since I would insert the query text in the method (see above) that 
is less of an issue.

> The SQL used:
>      SELECT used
>      FROM   usedProverbs
>      LIMIT  1
> 
> I defined usedProverbs as a sorted view (on proverbs), that is why
> there is no SORT BY.

Sorted view is another thing I would not do.  I am not sure that is even 
a supported features across most databases.  It does have issues - 
technical and conceptual.

With the SQL given the reader does not have a chance to identify the 
full criteria that select the value "used" because you do not see the 
sorting criteria.  I would rather put the "ORDER BY" into the query. 
(Or make it a query with "MIN" depending on schema.)  You can read a lot 
on the issues of sorting a view, for example here:

https://dba.stackexchange.com/questions/21434/why-does-order-by-not-belong-in-a-view/

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#37281

Robert Klemme <shortcutter@googlemail.com> writes:

> On 15.08.2017 08:12, Cecil Westerhof wrote:
>> Robert Klemme <shortcutter@googlemail.com> writes:
>>
>>> Btw. I'd rather throw in catch than return a special value.  That is
>>> cleaner and does not break if the special value actually occurs in the
>>> database.
>>
>> I agree. But that is what the call to fatalError does: it cleans up
>> resources and exits the program. But I changed that to just let the
>> SQLException fire:
>>      private static String getOldestUsed() throws SQLException {
>>          String oldestUsed = "";
>>
>>          try (SQLResultSet rsOldest = sqlite3Conn.executeQuery(OLDEST_USED)) {
>>              if (rsOldest.next()) {
>>                  oldestUsed = rsOldest.getString("used");
>>              }
>>          }
>>          return oldestUsed;
>>      }
>
> I'd rather
>
> private static String getOldestUsed() throws SQLException {
>     try (final SQLResultSet rs = sqlite3Conn.executeQuery(OLDEST_USED)) {
>         if (rs.next()) {
>             return rs.getString("used");
>         }
>     }
>
>     return "";
> }
>
>
> But religious wars have been fought about additional returns inside
> methods.  To me this reads easier because you see the fallback return
> value immediately and you can recognize immediately what value is
> returned.  In this smallish example it probably does not make a
> difference though.

I will think about it.


> Btw. SQL statements when used like this tend to be specific to the
> method.  So by inserting the SQL directly in the method instead of in a
> constant the reader has more information at hand and can quicker
> understand the logic.  Constants make much more more sense if the SQL is
> actually reused in different locations.

I find it handy to have all the definitions in one place. But again:
it does not hurt to think about it.


>>> And another remark: we do not see the SQL but in this case I would make
>>> sure that OLDEST_USED actually returns exactly one column and access
>>> that via index instead of name.  IIRC this tends to be slightly quicker.
>>> But it may be just an old habit of mine.
>>
>> One of the things I do is make sure you cannot use index. I find that
>> a very bad habit.
>
> Why?

I have to often seen that a database definition changed and there was
a big problem with the code, because a lot of queries had to be
changed.

I agree that with the kind of programs my wrapper will be used it
probably is mot a big deal, but it does not hurt to make people learn
to use better practises.


>> Also when you give the wrong query, but it gives one
>> column back, you have a hard to find bug.
>
> If the value happens to be of the same type as the expected one, yes.
> But since I would insert the query text in the method (see above) that
> is less of an issue.

When using the query text, yes. When using a constant no. And getXXX
will be used add places where there is used a constant.


>> The SQL used:
>>      SELECT used
>>      FROM   usedProverbs
>>      LIMIT  1
>>
>> I defined usedProverbs as a sorted view (on proverbs), that is why
>> there is no SORT BY.
>
> Sorted view is another thing I would not do.  I am not sure that is even
> a supported features across most databases.  It does have issues - 
> technical and conceptual.

In this case it is on a SQLite3 database which does have it and I
think it very unlikely to change. But you are right: when I want the
code to be portable I should not use this, or add a comment to the
code.


> With the SQL given the reader does not have a chance to identify the
> full criteria that select the value "used" because you do not see the
> sorting criteria.  I would rather put the "ORDER BY" into the query. (Or
> make it a query with "MIN" depending on schema.)

At least prepending MIN_ would be a good idea.


> You can read a lot on
> the issues of sorting a view, for example here:
>
> https://dba.stackexchange.com/questions/21434/why-does-order-by-not-belong-in-a-view/

I will evaluate that.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#37282

Cecil Westerhof <Cecil@decebal.nl> writes:

>>> The SQL used:
>>>      SELECT used
>>>      FROM   usedProverbs
>>>      LIMIT  1
>>>
>>> I defined usedProverbs as a sorted view (on proverbs), that is why
>>> there is no SORT BY.
>>
>> Sorted view is another thing I would not do.  I am not sure that is even
>> a supported features across most databases.  It does have issues - 
>> technical and conceptual.
>
> In this case it is on a SQLite3 database which does have it and I
> think it very unlikely to change. But you are right: when I want the
> code to be portable I should not use this, or add a comment to the
> code.

The double sort makes a HUGE difference. So big that it is even not
reasonable. My version (when executed in the DBBrowser) almost always
takes 0 ms and sometimes 1. When I add the ORDER BY it becomes between
13 and 16 ms. I would expect only sometimes 2 ms.

I already asked about this on the SQLite mailing-list.


>> With the SQL given the reader does not have a chance to identify the
>> full criteria that select the value "used" because you do not see the
>> sorting criteria.  I would rather put the "ORDER BY" into the query. (Or
>> make it a query with "MIN" depending on schema.)
>
> At least prepending MIN_ would be a good idea.

On second thought: the name is OLDEST_USED. I think that is clear
enough. ;-)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#37283

Cecil Westerhof <Cecil@decebal.nl> writes:

> Cecil Westerhof <Cecil@decebal.nl> writes:
>
>>>> The SQL used:
>>>>      SELECT used
>>>>      FROM   usedProverbs
>>>>      LIMIT  1
>>>>
>>>> I defined usedProverbs as a sorted view (on proverbs), that is why
>>>> there is no SORT BY.
>>>
>>> Sorted view is another thing I would not do.  I am not sure that is even
>>> a supported features across most databases.  It does have issues - 
>>> technical and conceptual.
>>
>> In this case it is on a SQLite3 database which does have it and I
>> think it very unlikely to change. But you are right: when I want the
>> code to be portable I should not use this, or add a comment to the
>> code.
>
> The double sort makes a HUGE difference. So big that it is even not
> reasonable. My version (when executed in the DBBrowser) almost always
> takes 0 ms and sometimes 1. When I add the ORDER BY it becomes between
> 13 and 16 ms. I would expect only sometimes 2 ms.

I made an unsorted view and if I use that the performance is like it
was. The sort was only added because I got a sorted list when looking
with DBBrowser at the data. But that is only one click and is not
something I do a lot, so I will remove the sorts from my views.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#37284

On 19.08.2017 13:46, Cecil Westerhof wrote:
> Cecil Westerhof <Cecil@decebal.nl> writes:

>>> With the SQL given the reader does not have a chance to identify the
>>> full criteria that select the value "used" because you do not see the
>>> sorting criteria.  I would rather put the "ORDER BY" into the query. (Or
>>> make it a query with "MIN" depending on schema.)
>>
>> At least prepending MIN_ would be a good idea.
> 
> On second thought: the name is OLDEST_USED. I think that is clear
> enough. ;-)

You are missing the point: I was suggesting to use a query that uses 
aggregate function MIN() to select the needed value - if the schema does 
support that.  Since you did not disclose the view and table definitions 
I cannot be more specific.

Cheers

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#37287

On 8/19/2017 9:35 AM, Robert Klemme wrote:
> On 19.08.2017 13:46, Cecil Westerhof wrote:
>> Cecil Westerhof <Cecil@decebal.nl> writes:
>>>> With the SQL given the reader does not have a chance to identify the
>>>> full criteria that select the value "used" because you do not see the
>>>> sorting criteria.  I would rather put the "ORDER BY" into the query. 
>>>> (Or
>>>> make it a query with "MIN" depending on schema.)
>>>
>>> At least prepending MIN_ would be a good idea.
>>
>> On second thought: the name is OLDEST_USED. I think that is clear
>> enough. ;-)
> 
> You are missing the point: I was suggesting to use a query that uses 
> aggregate function MIN() to select the needed value - if the schema does 
> support that.  Since you did not disclose the view and table definitions 
> I cannot be more specific.

MIN has to be there. It is basic SQL.

Arne

[toc] | [prev] | [next] | [standalone]

#37301

On 19.08.2017 15:48, Arne Vajhøj wrote:
> On 8/19/2017 9:35 AM, Robert Klemme wrote:
>> On 19.08.2017 13:46, Cecil Westerhof wrote:
>>> Cecil Westerhof <Cecil@decebal.nl> writes:
>>>>> With the SQL given the reader does not have a chance to identify the
>>>>> full criteria that select the value "used" because you do not see the
>>>>> sorting criteria.  I would rather put the "ORDER BY" into the 
>>>>> query. (Or
>>>>> make it a query with "MIN" depending on schema.)
>>>>
>>>> At least prepending MIN_ would be a good idea.
>>>
>>> On second thought: the name is OLDEST_USED. I think that is clear
>>> enough. ;-)
>>
>> You are missing the point: I was suggesting to use a query that uses 
>> aggregate function MIN() to select the needed value - if the schema 
>> does support that.  Since you did not disclose the view and table 
>> definitions I cannot be more specific.
> 
> MIN has to be there. It is basic SQL.
I said "depending on schema" - not database product or SQL dialect.

Cheers

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#37306

On 8/19/2017 5:26 PM, Robert Klemme wrote:
> On 19.08.2017 15:48, Arne Vajhøj wrote:
>> On 8/19/2017 9:35 AM, Robert Klemme wrote:
>>> You are missing the point: I was suggesting to use a query that uses 
>>> aggregate function MIN() to select the needed value - if the schema 
>>> does support that.  Since you did not disclose the view and table 
>>> definitions I cannot be more specific.
>>
>> MIN has to be there. It is basic SQL.
> I said "depending on schema" - not database product or SQL dialect.

I must be missing something.

If the database SQL supports MIN then I would expect it to always
be available independent of schema (both in the general meaning
and in the Oracle meaning of the term).

Arne

[toc] | [prev] | [next] | [standalone]

#37328

On 20.08.2017 02:01, Arne Vajhøj wrote:
> On 8/19/2017 5:26 PM, Robert Klemme wrote:
>> On 19.08.2017 15:48, Arne Vajhøj wrote:
>>> On 8/19/2017 9:35 AM, Robert Klemme wrote:
>>>> You are missing the point: I was suggesting to use a query that uses 
>>>> aggregate function MIN() to select the needed value - if the schema 
>>>> does support that.  Since you did not disclose the view and table 
>>>> definitions I cannot be more specific.
>>>
>>> MIN has to be there. It is basic SQL.
>> I said "depending on schema" - not database product or SQL dialect.
> 
> I must be missing something.
> 
> If the database SQL supports MIN then I would expect it to always
> be available independent of schema (both in the general meaning
> and in the Oracle meaning of the term).

Of course, but it depends on the schema whether MIN is required, an 
elegant solution or cannot be used to query the desired value.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#37288

Robert Klemme <shortcutter@googlemail.com> writes:

> On 19.08.2017 13:46, Cecil Westerhof wrote:
>> Cecil Westerhof <Cecil@decebal.nl> writes:
>
>>>> With the SQL given the reader does not have a chance to identify the
>>>> full criteria that select the value "used" because you do not see the
>>>> sorting criteria.  I would rather put the "ORDER BY" into the query. (Or
>>>> make it a query with "MIN" depending on schema.)
>>>
>>> At least prepending MIN_ would be a good idea.
>>
>> On second thought: the name is OLDEST_USED. I think that is clear
>> enough. ;-)
>
> You are missing the point: I was suggesting to use a query that uses
> aggregate function MIN() to select the needed value - if the schema does
> support that.  Since you did not disclose the view and table definitions
> I cannot be more specific.

Of-course: you are completely right, that is much better. I changed
it. Should have done it like that to begin with.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#37285

On 19.08.2017 12:54, Cecil Westerhof wrote:
> Robert Klemme <shortcutter@googlemail.com> writes:
>> On 15.08.2017 08:12, Cecil Westerhof wrote:

>>> One of the things I do is make sure you cannot use index. I find that
>>> a very bad habit.
>>
>> Why?
> 
> I have to often seen that a database definition changed and there was
> a big problem with the code, because a lot of queries had to be
> changed.

What does that have to do with accessing via index or name?  You are 
talking about changing queries because of changed schema.  But that does 
not necessarily have effects on the layout of the ResultSet.

> I agree that with the kind of programs my wrapper will be used it
> probably is mot a big deal, but it does not hurt to make people learn
> to use better practises.

Again, why is it a better practice to avoid accessing columns via index 
instead of name?

>> Sorted view is another thing I would not do.  I am not sure that is even
>> a supported features across most databases.  It does have issues -
>> technical and conceptual.
> 
> In this case it is on a SQLite3 database which does have it and I
> think it very unlikely to change. But you are right: when I want the
> code to be portable I should not use this, or add a comment to the
> code.

It's not only about portability.  It is also about conceptual issues.  A 
view is just a view on data.  In relational theory, which is the 
foundation of RDBMS and SQL, a view is just a special subset of the 
data.  (But do not make the mistake to reduce SQL to relational theory - 
it is actually more.)

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#37286

On 8/19/2017 9:35 AM, Robert Klemme wrote:
> On 19.08.2017 12:54, Cecil Westerhof wrote:
>> Robert Klemme <shortcutter@googlemail.com> writes:
>>> On 15.08.2017 08:12, Cecil Westerhof wrote:
>>>> One of the things I do is make sure you cannot use index. I find that
>>>> a very bad habit.
>>>
>>> Why?
>>
>> I have to often seen that a database definition changed and there was
>> a big problem with the code, because a lot of queries had to be
>> changed.
> 
> What does that have to do with accessing via index or name?  You are 
> talking about changing queries because of changed schema.  But that does 
> not necessarily have effects on the layout of the ResultSet.

Only if using *. And that is definitely a bad idea.

Arne

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web