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

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

Which databases are the most used with Java

Started byCecil Westerhof <Cecil@decebal.nl>
First post2017-08-13 07:58 +0200
Last post2017-08-23 12:09 +0200
Articles 20 on this page of 93 — 12 participants

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

Contents

  Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 07:58 +0200
    Re: Which databases are the most used with Java Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-08-13 09:33 +0200
      Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 11:14 +0200
      Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-13 16:53 -0400
    Re: Which databases are the most used with Java Sebastian <nowhere@nirvana.org> - 2017-08-13 09:36 +0200
      Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 11:07 +0200
        Re: Which databases are the most used with Java Andreas Leitgeb <avl@logic.at> - 2017-08-13 09:46 +0000
          Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 12:12 +0200
            Re: Which databases are the most used with Java Robert Klemme <shortcutter@googlemail.com> - 2017-08-13 17:47 +0200
              Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 19:11 +0200
                Re: Which databases are the most used with Java Robert Klemme <shortcutter@googlemail.com> - 2017-08-13 20:26 +0200
                  Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 21:30 +0200
                    Re: Which databases are the most used with Java Martin Gregorie <martin@address-in-sig.invalid> - 2017-08-13 20:00 +0000
                    Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-13 16:43 -0400
                Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-13 16:42 -0400
                  Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 23:18 +0200
                    Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-13 20:41 -0400
                      Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-14 03:04 +0200
                        Re: Which databases are the most used with Java lewbloch@gmail.com - 2017-08-14 11:12 -0700
                          Re: Which databases are the most used with Java Eric Douglas <e.d.programmer@gmail.com> - 2017-08-14 12:42 -0700
                      Re: Which databases are the most used with Java Robert Klemme <shortcutter@googlemail.com> - 2017-08-21 22:25 +0200
                        Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-21 19:50 -0400
                Re: Which databases are the most used with Java Eric Douglas <e.d.programmer@gmail.com> - 2017-08-14 13:48 -0700
                  Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-15 07:27 +0200
                    Re: Which databases are the most used with Java Martin Gregorie <martin@address-in-sig.invalid> - 2017-08-15 10:25 +0000
                      Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-15 14:15 +0200
                        Re: Which databases are the most used with Java Martin Gregorie <martin@address-in-sig.invalid> - 2017-08-15 14:37 +0000
                        Re: Which databases are the most used with Java lewbloch@gmail.com - 2017-08-17 14:52 -0700
                          Re: Which databases are the most used with Java Sebastian <nowhere@nirvana.org> - 2017-08-18 00:09 +0200
                          Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-17 18:14 -0400
                        Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-17 18:19 -0400
                          Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-18 06:43 +0200
                      Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-15 11:02 -0400
                    Re: Which databases are the most used with Java Patrick Roemer <sangamon@netcologne.de> - 2017-08-15 13:12 +0200
                      Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-15 14:41 +0200
                        Re: Which databases are the most used with Java Eric Douglas <e.d.programmer@gmail.com> - 2017-08-15 06:11 -0700
                          Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-15 16:33 +0200
                            Re: Which databases are the most used with Java Eric Douglas <e.d.programmer@gmail.com> - 2017-08-15 08:05 -0700
                              Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-15 18:48 +0200
                            Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-15 11:12 -0400
                              Re: Which databases are the most used with Java Eric Douglas <e.d.programmer@gmail.com> - 2017-08-15 08:19 -0700
                                Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-15 11:46 -0400
                            Re: Which databases are the most used with Java Eric Douglas <e.d.programmer@gmail.com> - 2017-08-15 08:43 -0700
                              Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-15 11:51 -0400
                              Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-15 18:38 +0200
                        Re: Which databases are the most used with Java Patrick Roemer <sangamon@netcologne.de> - 2017-08-15 16:14 +0200
                          Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-15 17:42 +0200
                        Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-15 11:09 -0400
                    Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-15 11:06 -0400
                      Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-15 18:42 +0200
                        Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-16 21:13 -0400
                          Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-17 09:04 +0200
                            Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-17 18:16 -0400
                              Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-18 06:51 +0200
                                Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-18 08:52 -0400
                                  Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-18 15:31 +0200
                                    Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-18 15:09 -0400
                                      Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-18 23:14 +0200
                                  Re: Which databases are the most used with Java Eric Douglas <e.d.programmer@gmail.com> - 2017-08-18 07:15 -0700
                                    Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-18 15:16 -0400
        Re: Which databases are the most used with Java Sebastian <nowhere@nirvana.org> - 2017-08-13 18:08 +0200
          Re: Which databases are the most used with Java Robert Klemme <shortcutter@googlemail.com> - 2017-08-13 20:30 +0200
            Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 21:35 +0200
              Re: Which databases are the most used with Java Sebastian <nowhere@nirvana.org> - 2017-08-13 22:24 +0200
                Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 23:33 +0200
                  Re: Which databases are the most used with Java Robert Klemme <shortcutter@googlemail.com> - 2017-08-14 18:18 +0200
                    Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-15 07:47 +0200
                Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-16 21:21 -0400
                  Re: Which databases are the most used with Java Sebastian <nowhere@nirvana.org> - 2017-08-17 23:33 +0200
                    Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-17 18:11 -0400
              Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 23:24 +0200
                Re: Which databases are the most used with Java Robert Klemme <shortcutter@googlemail.com> - 2017-08-14 18:14 +0200
                  Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-15 07:45 +0200
            Re: Which databases are the most used with Java Sebastian <nowhere@nirvana.org> - 2017-08-13 22:16 +0200
            Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-13 16:50 -0400
              Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 23:35 +0200
                Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-13 21:14 -0400
                  Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-14 10:24 +0200
          Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-13 16:45 -0400
            Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 23:36 +0200
              Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-13 20:42 -0400
                Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-14 03:06 +0200
        Re: Which databases are the most used with Java lewbloch@gmail.com - 2017-08-13 09:59 -0700
        Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-13 17:04 -0400
          Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-14 00:06 +0200
            Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-14 00:35 +0200
              Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-13 20:44 -0400
                Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-14 03:12 +0200
    Re: Which databases are the most used with Java Arne Vajhøj <arne@vajhoej.dk> - 2017-08-13 16:59 -0400
    Re: Which databases are the most used with Java Joerg Meier <joergmmeier@arcor.de> - 2017-08-16 07:26 +0200
      Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-16 09:40 +0200
    Re: Which databases are the most used with Java Graeme Geldenhuys <graemeg@example.net> - 2017-08-23 00:15 +0100
      Re: Which databases are the most used with Java Cecil Westerhof <Cecil@decebal.nl> - 2017-08-23 12:09 +0200

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#37244

FromEric Douglas <e.d.programmer@gmail.com>
Date2017-08-15 08:19 -0700
Message-ID<acdeef1d-26bd-43d2-ab72-93bd69b7f29f@googlegroups.com>
In reply to#37243
On Tuesday, August 15, 2017 at 11:12:46 AM UTC-4, Arne Vajhøj wrote:
> (BTW I think Oracle did it wrong rs is not closed)
> 
> Arne

Well, the javadoc "Releases this ResultSet object's database and JDBC resources immediately instead of waiting for this to happen when it is automatically closed.", so yeah should be best practice to call close as soon as you're done with it, otherwise it should close itself at some point so whether or when that's really required may depend on where it's used.

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

#37247

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-08-15 11:46 -0400
Message-ID<omv50o$iks$1@gioia.aioe.org>
In reply to#37244
On 8/15/2017 11:19 AM, Eric Douglas wrote:
> On Tuesday, August 15, 2017 at 11:12:46 AM UTC-4, Arne Vajhøj wrote:
>> (BTW I think Oracle did it wrong rs is not closed)
>
> Well, the javadoc "Releases this ResultSet object's database and
> JDBCresources immediately instead of waiting for this to happen when it is
> automatically closed.", so yeah should be best practice to call close as
> soon as you're done with it, otherwise it should close itself at some
> point so whether or when that's really required may depend on where it's
> used.

The fine print of the JDBC spec states that ResultSet's get closed when
the Statement gets closed.

But I prefer the explicit close or in newer code the try with resource.

Arne

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

#37245

FromEric Douglas <e.d.programmer@gmail.com>
Date2017-08-15 08:43 -0700
Message-ID<54246758-9876-4f41-a7ac-c2fff223a9e0@googlegroups.com>
In reply to#37238
On Tuesday, August 15, 2017 at 10:44:14 AM UTC-4, Cecil Westerhof wrote:
> 
> By the way at https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
> there is the following code:
>     try (Statement stmt = con.createStatement()) {
>         ResultSet rs = stmt.executeQuery(query);
> 
>         while (rs.next()) {
>             String coffeeName = rs.getString("COF_NAME");
>             int supplierID = rs.getInt("SUP_ID");
>             float price = rs.getFloat("PRICE");
>             int sales = rs.getInt("SALES");
>             int total = rs.getInt("TOTAL");
> 
>             System.out.println(coffeeName + ", " + supplierID + ", " + 
>                                price + ", " + sales + ", " + total);
>         }
>     } catch (SQLException e) {
>         JDBCTutorialUtilities.printSQLException(e);
>     }
> 
> Are you going to tell Oracle that they are doing it wrong?
> 

Here's another simple example, look one Statement instance, two ResultSet instance.

     public static void main(final String[] args) {
          try {
               Connection conn = DriverManager.getConnection(db_connect_string, db_userid, db_password);
               Statement stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);
               ResultSet rs = stmt.executeQuery("SELECT table_name FROM information_schema.tables");
               System.out.println(stmt.getClass());
               rs.last();
               System.out.println(rs.getRow());
               rs.close();
               rs = stmt.executeQuery("SELECT name from sys.columns");
               rs.last();
               System.out.println(rs.getRow());
               rs.close();
               stmt.close();
               conn.close();
          } catch (SQLException e) {
               e.printStackTrace();
          }
     }

For my test I just used public static final Strings for the getConnection.  If you have multiple users and/or databases you'll want to use arguments.
Statement is an interface, so technically you can't create one, and re-usability has nothing to do with PreparedStatement.  The getClass in my example returned a com.microsoft.sqlserver.jdbc.SQLServerStatement.

The close methods are optional.  The first thing I noticed in the Statement javadoc is a variable telling you there is a method getMoreResults() which may return more than one ResultSet from a single query, one at a time, and can automatically close one when you retrieve the next one.  Anything you ultimately fail to close should close itself in a cleanup section.

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

#37248

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-08-15 11:51 -0400
Message-ID<omv59o$j4v$1@gioia.aioe.org>
In reply to#37245
On 8/15/2017 11:43 AM, Eric Douglas wrote:
> Here's another simple example, look one Statement instance, two ResultSet instance.
>
>      public static void main(final String[] args) {
>           try {
>                Connection conn = DriverManager.getConnection(db_connect_string, db_userid, db_password);
>                Statement stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);
>                ResultSet rs = stmt.executeQuery("SELECT table_name FROM information_schema.tables");
>                System.out.println(stmt.getClass());
>                rs.last();
>                System.out.println(rs.getRow());
>                rs.close();
>                rs = stmt.executeQuery("SELECT name from sys.columns");

I don't think I would reuse the variable.

>                rs.last();
>                System.out.println(rs.getRow());
>                rs.close();
>                stmt.close();
>                conn.close();
>           } catch (SQLException e) {
>                e.printStackTrace();
>           }
>      }

> The close methods are optional.

Connection close is definitely not optional.

>                                 Anything you ultimately fail to close should
> close itself in a cleanup section.

Yes. Either catch or finally should close. Or the new try with resource
should be used instead.

Arne

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

#37250

FromCecil Westerhof <Cecil@decebal.nl>
Date2017-08-15 18:38 +0200
Message-ID<87tw18n5vs.fsf@munus.decebal.nl>
In reply to#37245
Eric Douglas <e.d.programmer@gmail.com> writes:

>      public static void main(final String[] args) {
>           try {
>                Connection conn = DriverManager.getConnection(db_connect_string, db_userid, db_password);
>                Statement stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);
>                ResultSet rs = stmt.executeQuery("SELECT table_name FROM information_schema.tables");
>                System.out.println(stmt.getClass());
>                rs.last();
>                System.out.println(rs.getRow());
>                rs.close();
>                rs = stmt.executeQuery("SELECT name from sys.columns");
>                rs.last();
>                System.out.println(rs.getRow());
>                rs.close();
>                stmt.close();
>                conn.close();
>           } catch (SQLException e) {
>                e.printStackTrace();
>           }
>      }

I would not write it like that. At least like this:
    public static void main(final String[] args) {
        try (Connection conn = DriverManager.getConnection(db_connect_string, db_userid, db_password);
             Statement stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY)){
            try (ResultSet rs = stmt.executeQuery("SELECT table_name FROM information_schema.tables")) {
                System.out.println(stmt.getClass());
                rs.last();
                System.out.println(rs.getRow());
            }
            try (ResultSet rs = stmt.executeQuery("SELECT name from sys.columns")) {
                rs.last();
                System.out.println(rs.getRow());
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

But I do not like this kind of code, so I would rewrite it to:
    public static void main(final String[] args) {
        try (Connection conn      = DriverManager.getConnection(db_connect_string, db_userid, db_password);
             Statement stmtTable  = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);
             ResultSet rsTable    = stmt.executeQuery("SELECT table_name FROM information_schema.tables");
             Statement stmtColumn = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);
             ResultSet rsColumn   = stmt.executeQuery("SELECT name from sys.columns")){
            System.out.println(stmtTable.getClass());
            rsTable.last();
            System.out.println(rsTable.getRow());
            rsColumn.last();
            System.out.println(rsColumn.getRow());
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

And I do not mind to get rid of those Statements.

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

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

#37236

FromPatrick Roemer <sangamon@netcologne.de>
Date2017-08-15 16:14 +0200
Message-ID<omuvks$t3j$1@newsreader4.netcologne.de>
In reply to#37234
Responding to Cecil Westerhof:
> Patrick Roemer <sangamon@netcologne.de> writes:
> 
>> Responding to Cecil Westerhof:
>>> Earlier I was told that the way to do things was something like:
>>>     try (Statement stmtOldest = conn.createStatement();
>>>          ResultSet rsOldest   = stmtOldest.executeQuery(OLDEST_USED)
>>>          Statement stmtNewest = conn.createStatement();
>>>          ResultSet rsNewest   = stmtNewest.executeQuery(OLDEST_USED)
>>>          Statement stmtCount  = conn.createStatement();
>>>          ResultSet rsCount    = stmtCount.executeQuery(OLDEST_USED)) {
>>
>> Sure about that? I haven't seen any such suggestion in recent threads.
>> To the contrary, more than once you have been advised to reuse one
>> statement to create multiple result sets in sequence.
> 
> Yes I am sure about that. But probably another thread.

I am sure I haven't seen it *in recent threads*. I'd love to see a
pointer to that post.

>> You seem to insist on Statement being an evil ploy designed by the JDBC
>> inventors to force you to write unnecessary boiler plate code when all
>> you want is just a ResultSet. Whatever follows from this line of
>> reasoning is not likely to be correct or useful, I'm afraid.
> 
> I do not see Statement as an evil ploy. But I think that with try with
> resources it is something you do not need explicit anymore.

This just doesn't make sense. try-with-resources is just syntactic
sugar for a try-catch-finally pattern, the semantics are unaffected.

In situations where you really only want a one-shot ResultSet, something
like your custom helper #executeQuery() method /may/ make sense. But
that would be just as useful or useless as with the "classic"
try-catch-finally pattern.

In almost all other cases, e.g. when sequencing a number of ResultSets,
one should go for reuse of a single, explicit Statement. If only because
bluntly creating one statement per ResultSet may be harmful for
performance - one cannot know how costly creation and teardown of a
Statement is going to be. And again, try-with-resources or try-catch
finally doesn't have any impact on this consideration.

Best regards,
Patrick

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

#37246

FromCecil Westerhof <Cecil@decebal.nl>
Date2017-08-15 17:42 +0200
Message-ID<87y3qkn8he.fsf@munus.decebal.nl>
In reply to#37236
Patrick Roemer <sangamon@netcologne.de> writes:

> Responding to Cecil Westerhof:
>> Patrick Roemer <sangamon@netcologne.de> writes:
>> 
>>> Responding to Cecil Westerhof:
>>>> Earlier I was told that the way to do things was something like:
>>>>     try (Statement stmtOldest = conn.createStatement();
>>>>          ResultSet rsOldest   = stmtOldest.executeQuery(OLDEST_USED)
>>>>          Statement stmtNewest = conn.createStatement();
>>>>          ResultSet rsNewest   = stmtNewest.executeQuery(OLDEST_USED)
>>>>          Statement stmtCount  = conn.createStatement();
>>>>          ResultSet rsCount    = stmtCount.executeQuery(OLDEST_USED)) {
>>>
>>> Sure about that? I haven't seen any such suggestion in recent threads.
>>> To the contrary, more than once you have been advised to reuse one
>>> statement to create multiple result sets in sequence.
>> 
>> Yes I am sure about that. But probably another thread.
>
> I am sure I haven't seen it *in recent threads*. I'd love to see a
> pointer to that post.

I have been a ‘little’ into discussions. So I have to look it up.


>>> You seem to insist on Statement being an evil ploy designed by the JDBC
>>> inventors to force you to write unnecessary boiler plate code when all
>>> you want is just a ResultSet. Whatever follows from this line of
>>> reasoning is not likely to be correct or useful, I'm afraid.
>> 
>> I do not see Statement as an evil ploy. But I think that with try with
>> resources it is something you do not need explicit anymore.
>
> This just doesn't make sense. try-with-resources is just syntactic
> sugar for a try-catch-finally pattern, the semantics are unaffected.
>
> In situations where you really only want a one-shot ResultSet, something
> like your custom helper #executeQuery() method /may/ make sense. But
> that would be just as useful or useless as with the "classic"
> try-catch-finally pattern.
>
> In almost all other cases, e.g. when sequencing a number of ResultSets,
> one should go for reuse of a single, explicit Statement. If only because
> bluntly creating one statement per ResultSet may be harmful for
> performance - one cannot know how costly creation and teardown of a
> Statement is going to be. And again, try-with-resources or try-catch
> finally doesn't have any impact on this consideration.

It of-course depends. I have written programs where I used (a
‘global’) Statement several times, but especially in short lived
desktop applications it is different.

It all started with a certain point where I needed three ResultSets.
Because a Statement can only have one concurrent ResultSet I needed
also three Statements. I did not like that. And that is where it all
started with.

The funny thing is that I do not need the three ResultSets anymore,
because while creating the wrapper I also created a function to get a
count. And this was where I needed the ResultSets for.


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

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

#37242

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-08-15 11:09 -0400
Message-ID<omv2qa$f5o$2@gioia.aioe.org>
In reply to#37234
On 8/15/2017 8:41 AM, Cecil Westerhof wrote:
> Patrick Roemer <sangamon@netcologne.de> writes:
>> You seem to insist on Statement being an evil ploy designed by the JDBC
>> inventors to force you to write unnecessary boiler plate code when all
>> you want is just a ResultSet. Whatever follows from this line of
>> reasoning is not likely to be correct or useful, I'm afraid.
>
> I do not see Statement as an evil ploy. But I think that with try with
> resources it is something you do not need explicit anymore.

Statement is a bit "thin" in functionality.

But as soon as you move to PreparedStatement then you need that
reference.

And my guess is that you should use PreparedStatement over Statement in 95+%
of cases.

Arne

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

#37241

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-08-15 11:06 -0400
Message-ID<omv2lm$f5o$1@gioia.aioe.org>
In reply to#37226
On 8/15/2017 1:27 AM, Cecil Westerhof wrote:
> Eric Douglas <e.d.programmer@gmail.com> writes:
>> On Sunday, August 13, 2017 at 1:14:17 PM UTC-4, Cecil Westerhof wrote:
>>> What is wrong about that? A Statement can only have one ResultSet. So
>>> if you have 10 (independent) ResultSets you have 10 Statements.
>>>
>>
>> Wrong, read the Javadoc.
>> http://docs.oracle.com/javase/8/docs/api/java/sql/CallableStatement.html
>> "can return one ResultSet object or multiple ResultSet objects"
>
> That is certainly interesting, but that extends PreparedStatement, not
> Statement.

CallableStatement extends PreparedStatement that extends Statement.

I did mention in a previous note that some databases allow multiple
SELECT in a single executeQuery.

Stored procedures execute via CallableStatement execute behaves
the same way.

> Earlier I was told that the way to do things was something like:
>     try (Statement stmtOldest = conn.createStatement();
>          ResultSet rsOldest   = stmtOldest.executeQuery(OLDEST_USED)
>          Statement stmtNewest = conn.createStatement();
>          ResultSet rsNewest   = stmtNewest.executeQuery(OLDEST_USED)
>          Statement stmtCount  = conn.createStatement();
>          ResultSet rsCount    = stmtCount.executeQuery(OLDEST_USED)) {

As long as you complete using a ResultSet before opening the next then
you can reuse the same Statement.

But if yo do not do that then using same Statement (and same Connection 
- unlike
it supports something like MARS) will get you in problems.

Arne

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

#37249

FromCecil Westerhof <Cecil@decebal.nl>
Date2017-08-15 18:42 +0200
Message-ID<87mv70n5pd.fsf@munus.decebal.nl>
In reply to#37241
Arne Vajhøj <arne@vajhoej.dk> writes:

> As long as you complete using a ResultSet before opening the next then
> you can reuse the same Statement.
>
> But if yo do not do that then using same Statement (and same Connection
> - unlike
> it supports something like MARS) will get you in problems.

And that was my use-case: one try with resources with multiple
ResultSets. ;-)

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

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

#37256

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-08-16 21:13 -0400
Message-ID<on2qjc$1tug$1@gioia.aioe.org>
In reply to#37249
On 8/15/2017 12:42 PM, Cecil Westerhof wrote:
> Arne Vajhøj <arne@vajhoej.dk> writes:
>> As long as you complete using a ResultSet before opening the next then
>> you can reuse the same Statement.
>>
>> But if yo do not do that then using same Statement (and same Connection
>> - unlike
>> it supports something like MARS) will get you in problems.
> 
> And that was my use-case: one try with resources with multiple
> ResultSets. ;-)

Yes.

But multiple result sets in the same try (on same statement/connection)
is enough to get you in problems.

Arne

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

#37258

FromCecil Westerhof <Cecil@decebal.nl>
Date2017-08-17 09:04 +0200
Message-ID<87k222lloh.fsf@munus.decebal.nl>
In reply to#37256
Arne Vajhøj <arne@vajhoej.dk> writes:

> On 8/15/2017 12:42 PM, Cecil Westerhof wrote:
>> Arne Vajhøj <arne@vajhoej.dk> writes:
>>> As long as you complete using a ResultSet before opening the next then
>>> you can reuse the same Statement.
>>>
>>> But if yo do not do that then using same Statement (and same Connection
>>> - unlike
>>> it supports something like MARS) will get you in problems.
>>
>> And that was my use-case: one try with resources with multiple
>> ResultSets. ;-)
>
> Yes.
>
> But multiple result sets in the same try (on same statement/connection)
> is enough to get you in problems.

That is why I started with the wrapper: to make sure that a Statement
is implicit generated.

There are some extra things added:
- displayMetaData
- getCount
- getDBName
- getDBVersion

And for SQLite3 I added:
- isDBLocked
- isDBLockedShowErr

I also added a main so that I can use the classes from a script. For
example to check about 20 SQLite3 databases about being locked:
    java -cp ${_classpath} nl.decebal.sql.SQLite3 --areDBsLockedShowErr ${_databases[*]}

If I want a message about the databases that are locked.

And:
    java -cp ${_classpath} nl.decebal.sql.SQLite3 --areDBsLocked ${_databases[*]}

If I want a message for every database.

For every database I have:
    --displayMetaData

With SQLite3 I get:
    Driver:
      name          = SQLiteJDBC
      version       = native
      major version = 1
      minor version = 1
    Database:
      name          = SQLite
      version       = 3.20.0
      major version = 3
      minor version = 0
    user name       = null

And with H2 I get:
    Driver:
      name          = H2 JDBC Driver
      version       = 1.3.176 (2014-04-05)
      major version = 1
      minor version = 3
    Database:
      name          = H2
      version       = 1.3.176 (2014-04-05)
      major version = 1
      minor version = 3
    user name       = SA

Is a bit old, but that is the latest stable.

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

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

#37265

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-08-17 18:16 -0400
Message-ID<on54kp$1clf$3@gioia.aioe.org>
In reply to#37258
On 8/17/2017 3:04 AM, Cecil Westerhof wrote:
> That is why I started with the wrapper: to make sure that a Statement
> is implicit generated.

> I also added a main so that I can use the classes from a script. For
> example to check about 20 SQLite3 databases about being locked:
>      java -cp ${_classpath} nl.decebal.sql.SQLite3 --areDBsLockedShowErr ${_databases[*]}
> 
> If I want a message about the databases that are locked.
> 
> And:
>      java -cp ${_classpath} nl.decebal.sql.SQLite3 --areDBsLocked ${_databases[*]}
> 
> If I want a message for every database.

Have you consider instead of having a Java main then do the scripting
in a JVM scripting language - Python (Jython), JavaScript (Nashorn or
Rhino) or whatever you happen to have skills in?

Arne

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

#37269

FromCecil Westerhof <Cecil@decebal.nl>
Date2017-08-18 06:51 +0200
Message-ID<87k221jx6m.fsf@munus.decebal.nl>
In reply to#37265
Arne Vajhøj <arne@vajhoej.dk> writes:

> On 8/17/2017 3:04 AM, Cecil Westerhof wrote:
>> That is why I started with the wrapper: to make sure that a Statement
>> is implicit generated.
>
>> I also added a main so that I can use the classes from a script. For
>> example to check about 20 SQLite3 databases about being locked:
>>      java -cp ${_classpath} nl.decebal.sql.SQLite3 --areDBsLockedShowErr ${_databases[*]}
>>
>> If I want a message about the databases that are locked.
>>
>> And:
>>      java -cp ${_classpath} nl.decebal.sql.SQLite3 --areDBsLocked ${_databases[*]}
>>
>> If I want a message for every database.
>
> Have you consider instead of having a Java main then do the scripting
> in a JVM scripting language - Python (Jython), JavaScript (Nashorn or
> Rhino) or whatever you happen to have skills in?

On linux bash (or another shell) is mostly used for crontab jobs and
the like. Because I am thinking about publishing it I think I should
at least have a bash implementation. But I could also write a groovy
implementation of-course.

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

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

#37270

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-08-18 08:52 -0400
Message-ID<on6nul$1gt3$1@gioia.aioe.org>
In reply to#37269
On 8/18/2017 12:51 AM, Cecil Westerhof wrote:
> Arne Vajhøj <arne@vajhoej.dk> writes:
>> On 8/17/2017 3:04 AM, Cecil Westerhof wrote:
>>> That is why I started with the wrapper: to make sure that a Statement
>>> is implicit generated.
>>
>>> I also added a main so that I can use the classes from a script. For
>>> example to check about 20 SQLite3 databases about being locked:
>>>       java -cp ${_classpath} nl.decebal.sql.SQLite3 --areDBsLockedShowErr ${_databases[*]}
>>>
>>> If I want a message about the databases that are locked.
>>>
>>> And:
>>>       java -cp ${_classpath} nl.decebal.sql.SQLite3 --areDBsLocked ${_databases[*]}
>>>
>>> If I want a message for every database.
>>
>> Have you consider instead of having a Java main then do the scripting
>> in a JVM scripting language - Python (Jython), JavaScript (Nashorn or
>> Rhino) or whatever you happen to have skills in?
> 
> On linux bash (or another shell) is mostly used for crontab jobs and
> the like. Because I am thinking about publishing it I think I should
> at least have a bash implementation. But I could also write a groovy
> implementation of-course.

Java is good at many things.

But for this sort of scripting I would go for a script language.

And JVM script languages can use your class directly.

Arne

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

#37271

FromCecil Westerhof <Cecil@decebal.nl>
Date2017-08-18 15:31 +0200
Message-ID<87ziaxhujr.fsf@munus.decebal.nl>
In reply to#37270
Arne Vajhøj <arne@vajhoej.dk> writes:

> On 8/18/2017 12:51 AM, Cecil Westerhof wrote:
>> Arne Vajhøj <arne@vajhoej.dk> writes:
>>> On 8/17/2017 3:04 AM, Cecil Westerhof wrote:
>>>> That is why I started with the wrapper: to make sure that a Statement
>>>> is implicit generated.
>>>
>>>> I also added a main so that I can use the classes from a script. For
>>>> example to check about 20 SQLite3 databases about being locked:
>>>>       java -cp ${_classpath} nl.decebal.sql.SQLite3 --areDBsLockedShowErr ${_databases[*]}
>>>>
>>>> If I want a message about the databases that are locked.
>>>>
>>>> And:
>>>>       java -cp ${_classpath} nl.decebal.sql.SQLite3 --areDBsLocked ${_databases[*]}
>>>>
>>>> If I want a message for every database.
>>>
>>> Have you consider instead of having a Java main then do the scripting
>>> in a JVM scripting language - Python (Jython), JavaScript (Nashorn or
>>> Rhino) or whatever you happen to have skills in?
>>
>> On linux bash (or another shell) is mostly used for crontab jobs and
>> the like. Because I am thinking about publishing it I think I should
>> at least have a bash implementation. But I could also write a groovy
>> implementation of-course.
>
> Java is good at many things.
>
> But for this sort of scripting I would go for a script language.
>
> And JVM script languages can use your class directly.

But then I have to maintain two programs: the Java and the scripting
language.
For me it would not be a problem to work with (for example) Groovy,
but for other people it could be.

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

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

#37274

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-08-18 15:09 -0400
Message-ID<on7e11$112p$1@gioia.aioe.org>
In reply to#37271
On 8/18/2017 9:31 AM, Cecil Westerhof wrote:
> Arne Vajhøj <arne@vajhoej.dk> writes:
>> Java is good at many things.
>>
>> But for this sort of scripting I would go for a script language.
>>
>> And JVM script languages can use your class directly.
> 
> But then I have to maintain two programs: the Java and the scripting
> language.
> For me it would not be a problem to work with (for example) Groovy,
> but for other people it could be.

Yes and no.

If this script is to be maintained by the software development
team, then Java is probably a very safe choice.

But if the script is to be maintained by sys adm or DBA
or OPS, then it is a completely different context. These
guys most likely do not know Java, but will knows various
scripting languages maybe including Python.

If you give those guys a Java library and Jython, then
they can maintain the scripts.

Arne

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

#37277

FromCecil Westerhof <Cecil@decebal.nl>
Date2017-08-18 23:14 +0200
Message-ID<87o9rcinnc.fsf@munus.decebal.nl>
In reply to#37274
Arne Vajhøj <arne@vajhoej.dk> writes:

> On 8/18/2017 9:31 AM, Cecil Westerhof wrote:
>> Arne Vajhøj <arne@vajhoej.dk> writes:
>>> Java is good at many things.
>>>
>>> But for this sort of scripting I would go for a script language.
>>>
>>> And JVM script languages can use your class directly.
>>
>> But then I have to maintain two programs: the Java and the scripting
>> language.
>> For me it would not be a problem to work with (for example) Groovy,
>> but for other people it could be.
>
> Yes and no.
>
> If this script is to be maintained by the software development
> team, then Java is probably a very safe choice.
>
> But if the script is to be maintained by sys adm or DBA
> or OPS, then it is a completely different context. These
> guys most likely do not know Java, but will knows various
> scripting languages maybe including Python.
>
> If you give those guys a Java library and Jython, then
> they can maintain the scripts.

I give them my bash script, this is at least on Linux the most used
scripting language. But it would not hurt to also give a python
example. That is also used a lot.

You keep me busy. ;-)


This is a stripped down version of my script.
#!/usr/bin/env bash

set -o errexit
set -o nounset


declare -r _classpath=…
declare -r _databases=(
    database1
    database2
    database3
    .
    .
    .
    databaseN
)
declare -r _scriptname=${0##*/}

declare database
declare parameter

case ${_scriptname} in
    checkLocksSQLite.sh)
        parameter="--areDBsLockedShowErr"
        ;;
    checkLocksSQLiteVerbose.sh)
        parameter="--areDBsLocked"
        ;;
    *)
        printf "Got an unknown command name: %s.\n" "${_scriptname}"
        exit 1
        ;;
esac
java -cp ${_classpath} nl.decebal.sql.SQLite3 "${parameter}" ${_databases[*]}

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

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

#37272

FromEric Douglas <e.d.programmer@gmail.com>
Date2017-08-18 07:15 -0700
Message-ID<e8424395-a11b-4588-af31-f344ab5d70c7@googlegroups.com>
In reply to#37270
On Friday, August 18, 2017 at 8:52:56 AM UTC-4, Arne Vajhøj wrote:
> Java is good at many things.
> 
> But for this sort of scripting I would go for a script language.
> 
> And JVM script languages can use your class directly.
> 
> Arne

If Java has to execute a script I would write it in Java code if possible, or else embed it in a jar if possible if it must be in another language.
If it's independent that's one thing, if another process is calling your Java code then executing the script, but if the script is executed from within the Java code I hate depending on external files.

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

#37275

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-08-18 15:16 -0400
Message-ID<on7edu$11jv$1@gioia.aioe.org>
In reply to#37272
On 8/18/2017 10:15 AM, Eric Douglas wrote:
> On Friday, August 18, 2017 at 8:52:56 AM UTC-4, Arne Vajhøj wrote:
>> Java is good at many things.
>>
>> But for this sort of scripting I would go for a script language.
>>
>> And JVM script languages can use your class directly.
> 
> If Java has to execute a script I would write it in Java code if
> possible, or else embed it in a jar if possible if it must be in
> another language. If it's independent that's one thing, if another
> process is calling your Java code then executing the script, but if
> the script is executed from within the Java code I hate depending on
> external files.

I was envisioning:
    script language -> Java
not:
    Java -> script language

Arne

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

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

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

csiph-web