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

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

#37162 — Which databases are the most used with Java

I am making a wrapper around JDBC. I myself only use SQLite3 (at the
moment), but I want to share it. Then I should implement (at least)
the most important databases. I am thinking that the following
probably are used a lot:
    SQlite
    MySQL
    MariaDB
    PostgreSQL
    Oracle
    SQLServer
    DB2
    H2
    Derby
    HyperSQL

I should -I think- at least write an implementation for those. I am
using Linux, but I understood that nowadays you can run SQLServer on
Linux. So it should be doable.

Are there any other database that I ‘should’ implement?

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

[toc] | [next] | [standalone]

#37163

On 13.08.17 07.58, Cecil Westerhof wrote:
> I am making a wrapper around JDBC. I myself only use SQLite3 (at the
> moment), but I want to share it. Then I should implement (at least)
> the most important databases.

??? - The JDBC API is common to all databases. That's the idea of it.
So what is the intention of your wrapper? Which services does it provide 
to the programmer?


> I should -I think- at least write an implementation for those. I am
> using Linux, but I understood that nowadays you can run SQLServer on
> Linux. So it should be doable.

Yes, you /can/. But except for that, do you know anybody who does this 
in a production environment? What should be the purpose of that?
This was just an experiment of Microsoft to be prepared for the future 
(not primarily for Linux).

> Are there any other database that I ‘should’ implement?

What database specific code are you going to implement? The 101th ORM?

Let's give a small hint: ORM and other SQL generators generate (maybe 
database specific) SQL code just for the purpose that it is parsed back 
into an execution tree one millisecond later. What is superfluous in 
this scenario?


Marcel

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

#37167

Marcel Mueller <news.5.maazl@spamgourmet.org> writes:

> On 13.08.17 07.58, Cecil Westerhof wrote:
>> I am making a wrapper around JDBC. I myself only use SQLite3 (at the
>> moment), but I want to share it. Then I should implement (at least)
>> the most important databases.
>
> ??? - The JDBC API is common to all databases. That's the idea of it.
> So what is the intention of your wrapper? Which services does it provide
> to the programmer?

See my reply to Sebastian.


>> I should -I think- at least write an implementation for those. I am
>> using Linux, but I understood that nowadays you can run SQLServer on
>> Linux. So it should be doable.
>
> Yes, you /can/. But except for that, do you know anybody who does this
> in a production environment? What should be the purpose of that?
> This was just an experiment of Microsoft to be prepared for the future
> (not primarily for Linux).

I think a lot of Windows computers do.

Java is Write Once, Run Everywhere. So if I write the implementation
then someone else can use it with SQLServer without needing to write
the implementation.


> Let's give a small hint: ORM and other SQL generators generate (maybe
> database specific) SQL code just for the purpose that it is parsed back
> into an execution tree one millisecond later. What is superfluous in
> this scenario?

Well, for simple applications that would be overkill.

Also I have seen many places (even in big companies) where only JDBC
is used.

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

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

#37201

On 8/13/2017 3:33 AM, Marcel Mueller wrote:
> What database specific code are you going to implement? The 101th ORM?
>
> Let's give a small hint: ORM and other SQL generators generate (maybe
> database specific) SQL code just for the purpose that it is parsed back
> into an execution tree one millisecond later. What is superfluous in
> this scenario?

My Java byte code will after javac and JVM JIT compiler end up as native
instructions - does that mean that I could just as well code is assembler?

:-)

I will claim that the fact that something high level get translated to
something lower level does not make the high level abstraction
worthless.

Arne

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

#37164

Am 13.08.2017 um 07:58 schrieb Cecil Westerhof:
> I am making a wrapper around JDBC. I myself only use SQLite3 (at the
> moment), but I want to share it. Then I should implement (at least)
> the most important databases. I am thinking that the following
> probably are used a lot:
>     SQlite
>     MySQL
>     MariaDB
>     PostgreSQL
>     Oracle
>     SQLServer
>     DB2
>     H2
>     Derby
>     HyperSQL
>
> I should -I think- at least write an implementation for those. I am
> using Linux, but I understood that nowadays you can run SQLServer on
> Linux. So it should be doable.
>
> Are there any other database that I ‘should’ implement?
>
May I ask, why are you writing that wrapper? For your own convenience, 
with a special purpose in mind? Or for pedagogical reasons? Or are you 
planning to provide vendor-independent database programming in a new 
library, open source or commercial?

I am asking, because there already are such libraries. To my mind, the 
most excellent is the remarkable JOOQ library (https://www.jooq.org/). 
The open source part of it is only for open source databases, though. 
But I am sure you can learn much from studying it, and reading Lukas 
Eder's (the author's) blog posts.

-- Sebastian

(PS: I am not affiliated with JOOQ in any way, I just think it's awesome.)

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

#37165

Sebastian <nowhere@nirvana.org> writes:

> Am 13.08.2017 um 07:58 schrieb Cecil Westerhof:
>> I am making a wrapper around JDBC. I myself only use SQLite3 (at the
>> moment), but I want to share it. Then I should implement (at least)
>> the most important databases. I am thinking that the following
>> probably are used a lot:
>>     SQlite
>>     MySQL
>>     MariaDB
>>     PostgreSQL
>>     Oracle
>>     SQLServer
>>     DB2
>>     H2
>>     Derby
>>     HyperSQL
>>
>> I should -I think- at least write an implementation for those. I am
>> using Linux, but I understood that nowadays you can run SQLServer on
>> Linux. So it should be doable.
>>
>> Are there any other database that I ‘should’ implement?
>>
> May I ask, why are you writing that wrapper? For your own convenience,
> with a special purpose in mind? Or for pedagogical reasons? Or are you
> planning to provide vendor-independent database programming in a new
> library, open source or commercial?

It started with that I really do not like:
        try (Statement stmt     = conn.createStatement();
             ResultSet rsOldest = sqlite3Conn.executeQuery(OLDEST_USED)) {

I now can do:
        try (SQLResultSet rsOldest = sqlite3Conn.executeQuery(OLDEST_USED)) {

Because getting count is something I think you do a lot, I also
defined (and probably will do others):
    getCount

It does not save a lot, but: many small ones, make a big one.


I also created some SQLite3 specific methods:
    getSQLiteVersion
    isDBLocked

For other databases I can then define other database specific
functions.

I think that it could be handy to half the resources to declare in
your try with resources and have some database specific functions
ready.

It is also handy not to need to remember the URL prefix. ;-)

And the helper functions can be nice.


It is mostly for getting my hands dirty, but if it could be useful for
others, it would not hurt to make it easy to use it for others. One
being that they do not need to implement it for there own database.


By the way: one thing that I am going to do is that I implement in
SQLResultSet:
    getXXX(String columnLabel)
but not:
    getXXX(int columnIndex)

Because I think you should never use that.


> I am asking, because there already are such libraries. To my mind, the
> most excellent is the remarkable JOOQ library (https://www.jooq.org/).
> The open source part of it is only for open source databases, though.
> But I am sure you can learn much from studying it, and reading Lukas
> Eder's (the author's) blog posts.

That would be certainly interesting to look at. But what I am trying
to do does not get even close to that.

You could say that what I make is interesting when you only write
something simple where jooq would be overkill.

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

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

#37168

Cecil Westerhof <Cecil@decebal.nl> wrote:
> It started with that I really do not like:
>         try (Statement stmt     = conn.createStatement();
>              ResultSet rsOldest = sqlite3Conn.executeQuery(OLDEST_USED)) {
> I now can do:
>         try (SQLResultSet rsOldest = sqlite3Conn.executeQuery(OLDEST_USED)) {

I want one Lego(tm) brick, so I'm going to write a method that takes an
acre of wood land, cuts down the trees, builds a factory that produces one
brick then knocks down the factory and plants trees - all in one call!
How convenient! ;-)

And if I ever need ten bricks, I'll just call it ten times...

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

#37170

Andreas Leitgeb <avl@logic.at> writes:

> Cecil Westerhof <Cecil@decebal.nl> wrote:
>> It started with that I really do not like:
>>         try (Statement stmt     = conn.createStatement();
>>              ResultSet rsOldest = sqlite3Conn.executeQuery(OLDEST_USED)) {
>> I now can do:
>>         try (SQLResultSet rsOldest = sqlite3Conn.executeQuery(OLDEST_USED)) {
>
> I want one Lego(tm) brick, so I'm going to write a method that takes an
> acre of wood land, cuts down the trees, builds a factory that produces one
> brick then knocks down the factory and plants trees - all in one call!
> How convenient! ;-)

I do nothing more as usual, I only hide the things that are not
important.
It is a bit like generics: first you needed to define the type on both
sides of the statement, now only at one.

With try with resources you never (I think) need a Statement. The
Statement is needed for the ResultSet. So I only want to create the
ResultSet and let it handle the implicit Statement.


> And if I ever need ten bricks, I'll just call it ten times...

If you need 10 ResultSets, you also need 10 Statements. That was the
reason I started with this exercise. And if I need 10 ResultSets, I
just saved typing in the code for getting 10 Statements. I am happy.
:-D

Also: with the not really needed Statements you increase the risk of
bugs.

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

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

#37182

On 13.08.2017 12:12, Cecil Westerhof wrote:
> Andreas Leitgeb <avl@logic.at> writes:

>> And if I ever need ten bricks, I'll just call it ten times...
> 
> If you need 10 ResultSets, you also need 10 Statements.

This is wrong.

> Also: with the not really needed Statements you increase the risk of
> bugs.

Not sure what you mean by that.

Cheers

	robert

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

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

#37187

Robert Klemme <shortcutter@googlemail.com> writes:

> On 13.08.2017 12:12, Cecil Westerhof wrote:
>> Andreas Leitgeb <avl@logic.at> writes:
>
>>> And if I ever need ten bricks, I'll just call it ten times...
>>
>> If you need 10 ResultSets, you also need 10 Statements.
>
> This is wrong.

What is wrong about that? A Statement can only have one ResultSet. So
if you have 10 (independent) ResultSets you have 10 Statements.


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

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

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

#37188

On 13.08.2017 19:11, Cecil Westerhof wrote:
> Robert Klemme <shortcutter@googlemail.com> writes:
> 
>> On 13.08.2017 12:12, Cecil Westerhof wrote:
>>> Andreas Leitgeb <avl@logic.at> writes:
>>
>>>> And if I ever need ten bricks, I'll just call it ten times...
>>>
>>> If you need 10 ResultSets, you also need 10 Statements.
>>
>> This is wrong.
> 
> What is wrong about that? A Statement can only have one ResultSet. So
> if you have 10 (independent) ResultSets you have 10 Statements.

There are several ways to get more than one ResultSet from a Statement. 
The simplest is to invoke executeQuery(String) multiple times.  There 
are more fancy approaches like the batch processing.

https://docs.oracle.com/javase/8/docs/api/java/sql/Statement.html

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

So the argument is, because there is a variable of type Statement and a 
variable of type ResultSet there are twice as many as with your wrapper 
where there is just one variable of type SQLResultSet.  And the more 
variables the bigger the risk for mistakes.  Do I understand your point 
correctly?

In this particular case the chance of mistakenly using the wrong of two 
variables is pretty small I'd say since the number of methods with 
identical signatures or even with identical names between Statement and 
ResultSet will be fairly small.

I still do not see the value in this approach.  The cost of creating and 
maintaining that wrapper library and not working with original types 
(for some RDBMS to use some special functionality you need to cast the 
interface types to concrete types of that DB) seems to outweigh the 
benefit.  That is, unless I have overlooked something.

Kind regards

	robert


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

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

#37190

Robert Klemme <shortcutter@googlemail.com> writes:

> On 13.08.2017 19:11, Cecil Westerhof wrote:
>> Robert Klemme <shortcutter@googlemail.com> writes:
>>
>>> On 13.08.2017 12:12, Cecil Westerhof wrote:
>>>> Andreas Leitgeb <avl@logic.at> writes:
>>>
>>>>> And if I ever need ten bricks, I'll just call it ten times...
>>>>
>>>> If you need 10 ResultSets, you also need 10 Statements.
>>>
>>> This is wrong.
>>
>> What is wrong about that? A Statement can only have one ResultSet. So
>> if you have 10 (independent) ResultSets you have 10 Statements.
>
> There are several ways to get more than one ResultSet from a Statement.
> The simplest is to invoke executeQuery(String) multiple times.  There
> are more fancy approaches like the batch processing.

Then you need several try with resources, or risk a resource leak.


>>>> 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.
>
> So the argument is, because there is a variable of type Statement and a
> variable of type ResultSet there are twice as many as with your wrapper
> where there is just one variable of type SQLResultSet.  And the more
> variables the bigger the risk for mistakes.  Do I understand your point
> correctly?
>
> In this particular case the chance of mistakenly using the wrong of two
> variables is pretty small I'd say since the number of methods with
> identical signatures or even with identical names between Statement and
> ResultSet will be fairly small.

When you have ten Statement variables that you use to generate 10
ResultSets and the names do not differ enough, then you can easily use
the wrong Statement variable when generating your ResultSet.


> I still do not see the value in this approach.  The cost of creating and
> maintaining that wrapper library and not working with original types
> (for some RDBMS to use some special functionality you need to cast the
> interface types to concrete types of that DB) seems to outweigh the
> benefit.  That is, unless I have overlooked something.

I find it handy. And I also like the exercise. I already learned a few
things.

I also think it is not really rocket science. Creating costs (a little
more as I expected) time, but when it is finished I do not think there
is a lot of maintenance. (I could be wrong naturally.)

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

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

#37192

On Sun, 13 Aug 2017 21:30:38 +0200, Cecil Westerhof wrote:

> Robert Klemme <shortcutter@googlemail.com> writes:
> 
>> On 13.08.2017 19:11, Cecil Westerhof wrote:
>>> Robert Klemme <shortcutter@googlemail.com> writes:
>>>
>>>> On 13.08.2017 12:12, Cecil Westerhof wrote:
>>>>> Andreas Leitgeb <avl@logic.at> writes:
>>>>
>>>>>> And if I ever need ten bricks, I'll just call it ten times...
>>>>>
>>>>> If you need 10 ResultSets, you also need 10 Statements.
>>>>
>>>> This is wrong.
>>>
>>> What is wrong about that? A Statement can only have one ResultSet. So
>>> if you have 10 (independent) ResultSets you have 10 Statements.
>>
>> There are several ways to get more than one ResultSet from a Statement.
>> The simplest is to invoke executeQuery(String) multiple times.  There
>> are more fancy approaches like the batch processing.
> 
> Then you need several try with resources, or risk a resource leak.
> 
> 
>>>>> 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.
>>
>> So the argument is, because there is a variable of type Statement and a
>> variable of type ResultSet there are twice as many as with your wrapper
>> where there is just one variable of type SQLResultSet.  And the more
>> variables the bigger the risk for mistakes.  Do I understand your point
>> correctly?
>>
>> In this particular case the chance of mistakenly using the wrong of two
>> variables is pretty small I'd say since the number of methods with
>> identical signatures or even with identical names between Statement and
>> ResultSet will be fairly small.
> 
> When you have ten Statement variables that you use to generate 10
> ResultSets and the names do not differ enough, then you can easily use
> the wrong Statement variable when generating your ResultSet.
> 
> 
>> I still do not see the value in this approach.  The cost of creating
>> and maintaining that wrapper library and not working with original
>> types (for some RDBMS to use some special functionality you need to
>> cast the interface types to concrete types of that DB) seems to
>> outweigh the benefit.  That is, unless I have overlooked something.
> 
> I find it handy. And I also like the exercise. I already learned a few
> things.
> 
> I also think it is not really rocket science. Creating costs (a little
> more as I expected) time, but when it is finished I do not think there
> is a lot of maintenance. (I could be wrong naturally.)

There is one other point to bear in mind: the more 'stuff' you bury in 
wrappers the more you'll lock trainee programmers into your toolset and 
this may have an adverse impact on their future employability. 

IMO this is a good reason for not using wrappers that do nothing except 
making otherwise repetitive code in to a "write once, use many times" 
module without adding any application-specific capabilities.

Of course, you may not be bothered by this, but I think it deserves a 
little thought. I did this once back in the early days when IDMSX was a 
go-to database and COBOL was the main application programming language. 
It improved coding productivity quite a bit, mainly because it let us 
write reasonably complete batch processes as plug-in modules that dropped 
into this chunk of code which started stuff up, handled the database and 
provided some debugging capability. Having it probably saved 15-20% of 
hand-written code per program - and the system needed quite a lot of 
these for overnight and general database management tasks. 

However, it also bit a less experienced programmer when he got another 
job - and this was an entirely unintended consequence.


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

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

#37198

On 8/13/2017 3:30 PM, Cecil Westerhof wrote:
> Robert Klemme <shortcutter@googlemail.com> writes:
>> On 13.08.2017 19:11, Cecil Westerhof wrote:
>>> Robert Klemme <shortcutter@googlemail.com> writes:
>>>> On 13.08.2017 12:12, Cecil Westerhof wrote:
>>>>> Andreas Leitgeb <avl@logic.at> writes:
>>>>>> And if I ever need ten bricks, I'll just call it ten times...
>>>>>
>>>>> If you need 10 ResultSets, you also need 10 Statements.
>>>>
>>>> This is wrong.
>>>
>>> What is wrong about that? A Statement can only have one ResultSet. So
>>> if you have 10 (independent) ResultSets you have 10 Statements.
>>
>> There are several ways to get more than one ResultSet from a Statement.
>> The simplest is to invoke executeQuery(String) multiple times.  There
>> are more fancy approaches like the batch processing.
>
> Then you need several try with resources, or risk a resource leak.

Yes.

:-)

Arne

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

#37197

On 8/13/2017 1:11 PM, Cecil Westerhof wrote:
> Robert Klemme <shortcutter@googlemail.com> writes:
>> On 13.08.2017 12:12, Cecil Westerhof wrote:
>>> Andreas Leitgeb <avl@logic.at> writes:
>>>> And if I ever need ten bricks, I'll just call it ten times...
>>>
>>> If you need 10 ResultSets, you also need 10 Statements.
>>
>> This is wrong.
>
> What is wrong about that? A Statement can only have one ResultSet. So
> if you have 10 (independent) ResultSets you have 10 Statements.

No.

A Statement can only have one ResultSet at a given time, but a Statement
can have multiple ResultSet's over time.

Statement stmt = con.createStatement();
ResultSet rs1 = stmt.executeQuery("...");
...
rs1.close();
ResultSet rs2 = stmt.executeQuery("...");
...
rs2.close();
stmt.close();

is a common construct.

(in newer code it would be one try Statement with two try ResultSet inside)

There are also the possibility in some databases to execute multiple
SELECT in a single execute/executeQuery and then you will get more than
one ResultSet back.

This is used like:

Statement stmt = con.createStatement();
ResultSet rs1 = stmt.executeQuery("...");
...
rs1.close();
stmt.getMoreResults();
ResultSet rs2 = stmt.getResultSet();
...
rs2.close();
stmt.close();

Arne

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

#37204

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

>> What is wrong about that? A Statement can only have one ResultSet. So
>> if you have 10 (independent) ResultSets you have 10 Statements.
>
> No.
>
> A Statement can only have one ResultSet at a given time, but a Statement
> can have multiple ResultSet's over time.
>
> Statement stmt = con.createStatement();
> ResultSet rs1 = stmt.executeQuery("...");
> ...
> rs1.close();
> ResultSet rs2 = stmt.executeQuery("...");
> ...
> rs2.close();
> stmt.close();
>
> is a common construct.
>
> (in newer code it would be one try Statement with two try ResultSet inside)
>
> There are also the possibility in some databases to execute multiple
> SELECT in a single execute/executeQuery and then you will get more than
> one ResultSet back.
>
> This is used like:
>
> Statement stmt = con.createStatement();
> ResultSet rs1 = stmt.executeQuery("...");
> ...
> rs1.close();
> stmt.getMoreResults();
> ResultSet rs2 = stmt.getResultSet();
> ...
> rs2.close();
> stmt.close();

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.

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

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

#37211

On 8/13/2017 5:18 PM, Cecil Westerhof wrote:
> Arne Vajhøj <arne@vajhoej.dk> writes:
>> There are also the possibility in some databases to execute multiple
>> SELECT in a single execute/executeQuery and then you will get more than
>> one ResultSet back.
>>
>> This is used like:
>>
>> Statement stmt = con.createStatement();
>> ResultSet rs1 = stmt.executeQuery("...");
>> ...
>> rs1.close();
>> stmt.getMoreResults();
>> ResultSet rs2 = stmt.getResultSet();
>> ...
>> rs2.close();
>> stmt.close();
>
> 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.

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

You need 3 levels of try.

Arne

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

#37216

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

> On 8/13/2017 5:18 PM, Cecil Westerhof wrote:
>> Arne Vajhøj <arne@vajhoej.dk> writes:
>>> There are also the possibility in some databases to execute multiple
>>> SELECT in a single execute/executeQuery and then you will get more than
>>> one ResultSet back.
>>>
>>> This is used like:
>>>
>>> Statement stmt = con.createStatement();
>>> ResultSet rs1 = stmt.executeQuery("...");
>>> ...
>>> rs1.close();
>>> stmt.getMoreResults();
>>> ResultSet rs2 = stmt.getResultSet();
>>> ...
>>> rs2.close();
>>> stmt.close();
>>
>> 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.
>
> You have 3 levels of resources: Connection, Statement, ResultSet.
>
> You need 3 levels of try.

Lets agree to disagree.

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

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

#37222

"Let's agree to disagree."

A suggestion most often proffered by an individual unwilling to fully understand the proposition with which they wish to disagree, or to face evidence that might change their mind.

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

#37223

On Monday, August 14, 2017 at 2:13:12 PM UTC-4, lewb...@gmail.com wrote:
> "Let's agree to disagree."
> 
> A suggestion most often proffered by an individual unwilling to fully understand the proposition with which they wish to disagree, or to face evidence that might change their mind.

The expression simply denotes an impasse, which means either one person is wrong and doesn't want to admit it, or both parties speak a matter of opinion which cannot be "changed by evidence".  If I say a glass is half full and you say it's half empty, both are right, just a matter of perspective.
(not a commentary on this specific thread as I didn't read the exchange in question)

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

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

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

csiph-web