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

Which databases are the most used with Java

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

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

  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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →

#37330

From	Robert Klemme <shortcutter@googlemail.com>
Date	2017-08-21 22:25 +0200
Message-ID	<f00tulFr5bkU1@mid.individual.net>
In reply to	#37211

On 14.08.2017 02:41, Arne Vajhøj wrote:
> On 8/13/2017 5:18 PM, Cecil Westerhof wrote:

>> Since Java7 we (or at least I) do not program that way anymore. You
>> use try with resources. You only want the ResultSet, but to prevent a
>> resource leak, you need to also create the Statement. That makes my
>> hair stand up on the back of my neck.

I don't know why it does so nasty things to your hair.  You could wrap 
your typical use cases easily in a (static) method that accepts a query 
string and a Function which accepts a ResultSet and do the resource 
cleanup in the static function.

> You have 3 levels of resources: Connection, Statement, ResultSet.
> 
> You need 3 levels of try.

It depends: you can get away with two levels if Statements do not live 
much longer than ResultSets or if you only want to make sure resources 
are released eventually because closing the Statement will implicitly 
close the ResultSet as well.

Kind regards

	robert

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

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

#37333

From	Arne Vajhøj <arne@vajhoej.dk>
Date	2017-08-21 19:50 -0400
Message-ID	<onfrkq$1lti$1@gioia.aioe.org>
In reply to	#37330

On 8/21/2017 4:25 PM, Robert Klemme wrote:
> On 14.08.2017 02:41, Arne Vajhøj wrote:
>> You have 3 levels of resources: Connection, Statement, ResultSet.
>>
>> You need 3 levels of try.
> 
> It depends: you can get away with two levels if Statements do not live 
> much longer than ResultSets or if you only want to make sure resources 
> are released eventually because closing the Statement will implicitly 
> close the ResultSet as well.

True.

s/need/should consider it natural to use/w

Arne

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

#37224

From	Eric Douglas <e.d.programmer@gmail.com>
Date	2017-08-14 13:48 -0700
Message-ID	<afdc32bc-17ff-4ee9-ade0-c7345f805585@googlegroups.com>
In reply to	#37187

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"

Even if using a PreparedStatement you may call it many times using the IN parameters, or using a GUI interface with a Refresh button.

> 
> >> Also: with the not really needed Statements you increase the risk of
> >> bugs.
> >
> > Not sure what you mean by that.
> 
> It would not be the first time that someone used similar names for
> different variables and use the wrong one at a certain point. When you
> double your variables, you increase the risk of making a mistake.
> 

It is easy to screw up code if you use variable names like rs1, rs2, rs3.  This is why Java is a wordy language.  If they're different purpose try different names when you get beyond simple test code, rsCustomers, rsInvoices.  Possibly they're just held in one list or map object, or you're just reusing one variable.

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

#37226

From	Cecil Westerhof <Cecil@decebal.nl>
Date	2017-08-15 07:27 +0200
Message-ID	<87h8x9pfi8.fsf@munus.decebal.nl>
In reply to	#37224

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.

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)) {

I prefer:
    try (ResultSet rsOldest   = SQLite3Conn.executeQuery(OLDEST_USED)
         ResultSet rsNewest   = SQLite3Conn.executeQuery(OLDEST_USED)
         ResultSet rsCount    = SQLite3Conn.executeQuery(OLDEST_USED)) {

You can disagree that the second is better as the first, but I prefer
the second. Even if I only need one ResultSet, which is most of the
time.

And certainly when I need 10 ResultSets I would prefer that.


>> >> Also: with the not really needed Statements you increase the risk of
>> >> bugs.
>> >
>> > Not sure what you mean by that.
>> 
>> It would not be the first time that someone used similar names for
>> different variables and use the wrong one at a certain point. When you
>> double your variables, you increase the risk of making a mistake.
>> 
>
> It is easy to screw up code if you use variable names like rs1, rs2,
> rs3. This is why Java is a wordy language. If they're different purpose
> try different names when you get beyond simple test code, rsCustomers,
> rsInvoices. Possibly they're just held in one list or map object, or
> you're just reusing one variable.

I do not have control over the variable names that other people use.
It is a bit like: seat belts are not necessary, you just have to make
sure you do not bump into something.

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

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

#37231

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2017-08-15 10:25 +0000
Message-ID	<omui7c$j91$1@dont-email.me>
In reply to	#37226

On Tue, 15 Aug 2017 07:27:27 +0200, Cecil Westerhof wrote:

> That is certainly interesting, but that extends PreparedStatement, not
> Statement.
>
Slightly OT, but PreparedStatement() is to be preferred to 
Statement.execute() especially if any part of the SQL query originates 
outside the application executing it. There are two reasons for this:

- since some RDBMS allow the execution plan for a query to be calculated
  and stored for future use by PreparedStatement, using it is likely to
  be more efficient if the query will be run more than once with
  different parameters, i.e. the values used to select rows, create new
  rows or amend row content. 

- Using a prepared statement prevents SQL injection attacks from
  succeeding because all externally supplied input is strictly
  constrained to be used as field values and, no matter how it is
  constructed, cannot subvert the structure of the query.

  IOW, it prevents 'Little Bobby Tables' exploits. 
  See https://xkcd.com/327/ if you don't recognise the reference.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#37233

From	Cecil Westerhof <Cecil@decebal.nl>
Date	2017-08-15 14:15 +0200
Message-ID	<87inhpni1f.fsf@munus.decebal.nl>
In reply to	#37231

Martin Gregorie <martin@address-in-sig.invalid> writes:

> On Tue, 15 Aug 2017 07:27:27 +0200, Cecil Westerhof wrote:
>
>> That is certainly interesting, but that extends PreparedStatement, not
>> Statement.
>>
> Slightly OT, but PreparedStatement() is to be preferred to 
> Statement.execute() especially if any part of the SQL query originates 
> outside the application executing it. There are two reasons for this:

I agree wholeheartedly, but I have queries that are hard coded. For
example:
    SELECT COUNT(*) as count
    FROM   usedProverbs

I do not think I should use a PreparedStatement there.


When there is input (even if it is generated by my own program) I
always use PreparedStatement.

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

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

#37237

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2017-08-15 14:37 +0000
Message-ID	<omv0v8$3ja$1@dont-email.me>
In reply to	#37233

On Tue, 15 Aug 2017 14:15:40 +0200, Cecil Westerhof wrote:

> I agree wholeheartedly, but I have queries that are hard coded. For
> example:
>     SELECT COUNT(*) as count FROM   usedProverbs
> 
> I do not think I should use a PreparedStatement there.
>
Fair enough. 

Whether PreparedStatement would help at all depends on the RDBMS and use 
frequency: even a simple query like that might benefit if its used 
everywhere and the RDBMS doesn't recreate the execution strategy each 
time its used.

A case in point might be where you're using something like a soft dbk as 
a table's prime key but the RDBMS doesn't support either autoincrementing 
fields or sequence objects, so you have to increment the stored sdbk seed 
and then copy the incremented value.

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#37261

From	lewbloch@gmail.com
Date	2017-08-17 14:52 -0700
Message-ID	<f21ba246-748d-45db-a29d-8d3710d9fafd@googlegroups.com>
In reply to	#37233

So when a query is hardcoded you prefer to give up the efficiency of `PreparedStatement`?

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

#37262

From	Sebastian <nowhere@nirvana.org>
Date	2017-08-18 00:09 +0200
Message-ID	<on546r$sr7$1@news.albasani.net>
In reply to	#37261

Am 17.08.2017 um 23:52 schrieb lewbloch@gmail.com:
> So when a query is hardcoded you prefer to give up the efficiency of `PreparedStatement`?
>
This remark, not quoting the relevant previous conversation, is hard to 
understand in isolation. "A query" sounds like a singular noun, i. e. a 
query that is done only once. "Hard-coded" sounds like "always the 
same", i. e. no arguments. In both these cases, PreparedStatement is not 
necessarily more efficient. Many databases can cache "hard-coded" 
statements anyway, so that there is often no measurable performance 
difference to using a PreparedStatement when executing the same 
statement another time.

-- Sebastian

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

#37264

From	Arne Vajhøj <arne@vajhoej.dk>
Date	2017-08-17 18:14 -0400
Message-ID	<on54fl$1clf$2@gioia.aioe.org>
In reply to	#37261

On 8/17/2017 5:52 PM, lewbloch@gmail.com wrote:
> So when a query is hardcoded you prefer to give up the efficiency of `PreparedStatement`?

The *potential* efficiency.

JDBC standard does not guarantee any extra efficiency by using
PreparedStatement over plain Statement.

Some databases may cache execution plans for PreparedStatement but
not for over plain Statement.

Other does not make a difference.

It is my impression that most databases today cache execution
plans even for plain Statement.

Arne

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

#37266

From	Arne Vajhøj <arne@vajhoej.dk>
Date	2017-08-17 18:19 -0400
Message-ID	<on54oj$1clf$4@gioia.aioe.org>
In reply to	#37233

On 8/15/2017 8:15 AM, Cecil Westerhof wrote:
> When there is input (even if it is generated by my own program) I
> always use PreparedStatement.

I love configuring some code to use H2 and then run it
with connection URL ending in:
     ;ALLOW_LITERALS=NONE

:-)

Arne

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

#37267

From	Cecil Westerhof <Cecil@decebal.nl>
Date	2017-08-18 06:43 +0200
Message-ID	<87o9rdjxj0.fsf@munus.decebal.nl>
In reply to	#37266

Arne Vajhøj <arne@vajhoej.dk> writes:

> On 8/15/2017 8:15 AM, Cecil Westerhof wrote:
>> When there is input (even if it is generated by my own program) I
>> always use PreparedStatement.
>
> I love configuring some code to use H2 and then run it
> with connection URL ending in:
>     ;ALLOW_LITERALS=NONE

I did not know that. Thanks for the tip.

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

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

#37239

From	Arne Vajhøj <arne@vajhoej.dk>
Date	2017-08-15 11:02 -0400
Message-ID	<omv2dv$etg$1@gioia.aioe.org>
In reply to	#37231

On 8/15/2017 6:25 AM, Martin Gregorie wrote:
> On Tue, 15 Aug 2017 07:27:27 +0200, Cecil Westerhof wrote:
>> That is certainly interesting, but that extends PreparedStatement, not
>> Statement.
>
> Slightly OT, but PreparedStatement() is to be preferred to
> Statement.execute()

Sure but the specific link is to CallableStatement that
extends PreparedStatement so it is fine.

Arne

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

#37232

From	Patrick Roemer <sangamon@netcologne.de>
Date	2017-08-15 13:12 +0200
Message-ID	<omukv5$m10$1@newsreader4.netcologne.de>
In reply to	#37226

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.

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.

Best regards,
Patrick

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

#37234

From	Cecil Westerhof <Cecil@decebal.nl>
Date	2017-08-15 14:41 +0200
Message-ID	<877ey5ngtu.fsf@munus.decebal.nl>
In reply to	#37232

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.


> 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.
If you do not like what I am making, nobody forces you to use it.


And even if it is useless, I am learning while making it.

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

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

#37235

From	Eric Douglas <e.d.programmer@gmail.com>
Date	2017-08-15 06:11 -0700
Message-ID	<6b0c0b97-8517-4f08-b512-fc3f3054fbb6@googlegroups.com>
In reply to	#37234

On Tuesday, August 15, 2017 at 8:44:21 AM UTC-4, Cecil Westerhof wrote:
> > 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.
> 
> 
> > 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.
> If you do not like what I am making, nobody forces you to use it.
> 
> 
> And even if it is useless, I am learning while making it.
> 

You are not learning if you completely ignore what everyone is telling you.
Again, read the javadocs.  You are not intended to create one Statement for every single ResultSet.
http://docs.oracle.com/javase/8/docs/api/java/sql/Connection.html#createStatement-int-int-
"Creates a Statement object that will generate ResultSet objects"
objects, plural.

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

#37238

From	Cecil Westerhof <Cecil@decebal.nl>
Date	2017-08-15 16:33 +0200
Message-ID	<87378soq8a.fsf@munus.decebal.nl>
In reply to	#37235

Eric Douglas <e.d.programmer@gmail.com> writes:

> On Tuesday, August 15, 2017 at 8:44:21 AM UTC-4, Cecil Westerhof wrote:
>> > 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.
>> 
>> 
>> > 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.
>> If you do not like what I am making, nobody forces you to use it.
>> 
>> 
>> And even if it is useless, I am learning while making it.
>> 
>
> You are not learning if you completely ignore what everyone is
> telling you.

Are you trolling me? If you had paid a little attention you would have
seen that I implemented suggestions. How is that completely ignoring
what everyone is telling me?


> Again, read the javadocs.  You are not intended to create one Statement for every single ResultSet.
> http://docs.oracle.com/javase/8/docs/api/java/sql/Connection.html#createStatement-int-int-
> "Creates a Statement object that will generate ResultSet objects"
> objects, plural.

And it ends with: Since: 1.2. I am using a version of Java that is a
little newer.

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?

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

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

#37240

From	Eric Douglas <e.d.programmer@gmail.com>
Date	2017-08-15 08:05 -0700
Message-ID	<f6dc7c44-f248-481a-8660-db03242ed00a@googlegroups.com>
In reply to	#37238

On Tuesday, August 15, 2017 at 10:44:14 AM UTC-4, Cecil Westerhof wrote:
> Are you trolling me? If you had paid a little attention you would have
> seen that I implemented suggestions. How is that completely ignoring
> what everyone is telling me?
> 
You sure look like a troll.  You've repeatedly stated you want to require the creation of a Statement instance literally every time you generate a ResultSet instance besides everyone telling you otherwise.

> 
> > Again, read the javadocs.  You are not intended to create one Statement for every single ResultSet.
> > http://docs.oracle.com/javase/8/docs/api/java/sql/Connection.html#createStatement-int-int-
> > "Creates a Statement object that will generate ResultSet objects"
> > objects, plural.
> 
> And it ends with: Since: 1.2. I am using a version of Java that is a
> little newer.
> 
You're suggesting they went backwards, didn't update the javadoc, and now a Statement is required for every ResultSet instance 1:1?  I think java.lang.String has been part of Java since 1.0, better stop using that.

> 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?
> 

Doing what wrong?  A simple example creates one instance of Statement which generates one instance of ResultSet.  That is not to say that stmt cannot be used to create a second ResultSet.

A convenience method to pass through from java.sql.Connection to generating one java.sql.ResultSet may be useful, if I'm writing a report I may know my statement will only execute once, but often Statement instance is re-used.  If my query populates a GUI screen with a refresh button I don't need a new statement every time.  I am generating a new instance of ResultSet every time (may re-use the variable).

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

#37251

From	Cecil Westerhof <Cecil@decebal.nl>
Date	2017-08-15 18:48 +0200
Message-ID	<87inhon5er.fsf@munus.decebal.nl>
In reply to	#37240

Eric Douglas <e.d.programmer@gmail.com> writes:

> On Tuesday, August 15, 2017 at 10:44:14 AM UTC-4, Cecil Westerhof wrote:
>> Are you trolling me? If you had paid a little attention you would have
>> seen that I implemented suggestions. How is that completely ignoring
>> what everyone is telling me?
>> 
> You sure look like a troll. You've repeatedly stated you want to require
> the creation of a Statement instance literally every time you generate a
> ResultSet instance besides everyone telling you otherwise.

Who is troll? I at least respond on what is said.

I NEVER said that I want to require the creation of a Statement
instance literally every time I generate a ResultSet instance. I DID
say that when I only need the Statement for one ResultSet, that I want
the Statement created implicitly.

You should read this:
    https://en.wikipedia.org/wiki/Straw_man

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

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

#37243

From	Arne Vajhøj <arne@vajhoej.dk>
Date	2017-08-15 11:12 -0400
Message-ID	<omv30u$frf$1@gioia.aioe.org>
In reply to	#37238

On 8/15/2017 10:33 AM, Cecil Westerhof wrote:
> Eric Douglas <e.d.programmer@gmail.com> writes:
>> Again, read the javadocs.  You are not intended to create one Statement for every single ResultSet.
>> http://docs.oracle.com/javase/8/docs/api/java/sql/Connection.html#createStatement-int-int-
>> "Creates a Statement object that will generate ResultSet objects"
>> objects, plural.
>
> And it ends with: Since: 1.2. I am using a version of Java that is a
> little newer.

That just mean that method has been available since 1.2 - not that it
should not be used with newer versions.

> 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?

They use 1 Statement to 1 ResultSet - it does not show either
1 Statement N ResultSet or N Statement N ResultSet.

(BTW I think Oracle did it wrong rs is not closed)

Arne

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

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

csiph-web

Which databases are the most used with Java

Contents

#37330

#37333

#37224

#37226

#37231

#37233

#37237

#37261

#37262

#37264

#37266

#37267

#37239

#37232

#37234

#37235

#37238

#37240

#37251

#37243