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

#37183

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

Back to the original question: In 15 years of development work for midle 
to large sized companies I have never seen an open source database used 
in the production environment, it's mostly Oracle, SQLServer, and DB2, 
with the single exception of PostgreSQL.

And this is usually independent of the choice of programming language. 
What does happen sometimes is that companies go for an entire integrated 
stack of products, such as deciding to use Oracle and doing all 
development with an Oracle-based framework such as ADF inside Oracle 
JDeveloper etc.

-- Sebastian

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

#37189

On 13.08.2017 18:08, Sebastian wrote:
>>> 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?
> 
> Back to the original question: In 15 years of development work for midle 
> to large sized companies I have never seen an open source database used 
> in the production environment, it's mostly Oracle, SQLServer, and DB2, 
> with the single exception of PostgreSQL.

Now I'm confused: did you see an OSS DB in production - or not? :-)

Another aspect of the original question that puzzled me right from the 
start: why does it matter at all what JDBC driver is really used.  Since 
all the types are interfaces anyway _any_ JDBC driver should work with 
the wrapper library (except vendor specific things which require 
specific types anyway).

Kind regards

	robert

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

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

#37191

Robert Klemme <shortcutter@googlemail.com> writes:

> Another aspect of the original question that puzzled me right from the
> start: why does it matter at all what JDBC driver is really used.  Since
> all the types are interfaces anyway _any_ JDBC driver should work with
> the wrapper library (except vendor specific things which require
> specific types anyway).

The only things that differs (as long as you only use generic
functionality) is the URLPrefix. That is why I think it is not much
work to generate the other concrete classes when the abstract and
first concrete class are finished.

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

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

#37194

Am 13.08.2017 um 21:35 schrieb Cecil Westerhof:
> Robert Klemme <shortcutter@googlemail.com> writes:
>
>> Another aspect of the original question that puzzled me right from the
>> start: why does it matter at all what JDBC driver is really used.  Since
>> all the types are interfaces anyway _any_ JDBC driver should work with
>> the wrapper library (except vendor specific things which require
>> specific types anyway).
>
> The only things that differs (as long as you only use generic
> functionality) is the URLPrefix. That is why I think it is not much
> work to generate the other concrete classes when the abstract and
> first concrete class are finished.
>
That's a bit optimistic. JDBC as a standard is a little vague, and 
surprising things can happen, starting with your mapping from database 
types to Java SQL types (NUMERIC?, REAL?, DECIMAL?... - and this can 
change even when updating from version of a driver to another of the 
same vendor). Then there are the peculiarities of caching, dealing with 
cursors, how to write your queries they are optimized etc. A _good_ 
abstraction over JDBC has to deal with all this kind of stuff and more, 
and has to keep up with changes in the databases it supports and their 
official drivers.

I agree with the sentiment expressed by Lew and Martin: A wrapper around 
trivial code that provides no useful abstractions, and just saves you 
some typing, may do more harm than good in the long run.

-- Sebastian

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

#37208

Sebastian <nowhere@nirvana.org> writes:

> Am 13.08.2017 um 21:35 schrieb Cecil Westerhof:
>> Robert Klemme <shortcutter@googlemail.com> writes:
>>
>>> Another aspect of the original question that puzzled me right from the
>>> start: why does it matter at all what JDBC driver is really used.  Since
>>> all the types are interfaces anyway _any_ JDBC driver should work with
>>> the wrapper library (except vendor specific things which require
>>> specific types anyway).
>>
>> The only things that differs (as long as you only use generic
>> functionality) is the URLPrefix. That is why I think it is not much
>> work to generate the other concrete classes when the abstract and
>> first concrete class are finished.
>>
> That's a bit optimistic. JDBC as a standard is a little vague, and

I am know for being optimistic. :-D


> surprising things can happen, starting with your mapping from database
> types to Java SQL types (NUMERIC?, REAL?, DECIMAL?... - and this can
> change even when updating from version of a driver to another of the
> same vendor). Then there are the peculiarities of caching, dealing with
> cursors, how to write your queries they are optimized etc. A _good_
> abstraction over JDBC has to deal with all this kind of stuff and more,
> and has to keep up with changes in the databases it supports and their
> official drivers.

I need to be more clear again.
I am making it for SQLite3. There you do not have cursors. My
intention is to only use it for small applications where you only do
simple work:
- updating
- deleting
- inserting
- traveling a ResultSet in one direction
- …

I think that when you do more as this, that you should switch to for
example JPA.


I will make at least also a H2 version (that is the other database I
am -still- using). Maybe I should not publish it. Or if I do: with a
big disclaimer.

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

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

#37221

On 13.08.2017 23:33, Cecil Westerhof wrote:

> I am making it for SQLite3. There you do not have cursors.

Sure?  How then does SQLite traverse a ResultSet?

https://sqlite.org/capi3ref.html#sqlite3_vtab_cursor

Cheers

	robert

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

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

#37228

Robert Klemme <shortcutter@googlemail.com> writes:

> On 13.08.2017 23:33, Cecil Westerhof wrote:
>
>> I am making it for SQLite3. There you do not have cursors.
>
> Sure?  How then does SQLite traverse a ResultSet?
>
> https://sqlite.org/capi3ref.html#sqlite3_vtab_cursor

Got my lingo wrong: I thought that a cursor was when you could travel
both ways and could set the position of the cursor.

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

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

#37257

On 8/13/2017 4:24 PM, Sebastian wrote:
> Am 13.08.2017 um 21:35 schrieb Cecil Westerhof:
>> Robert Klemme <shortcutter@googlemail.com> writes:
>>> Another aspect of the original question that puzzled me right from the
>>> start: why does it matter at all what JDBC driver is really used.  Since
>>> all the types are interfaces anyway _any_ JDBC driver should work with
>>> the wrapper library (except vendor specific things which require
>>> specific types anyway).
>>
>> The only things that differs (as long as you only use generic
>> functionality) is the URLPrefix. That is why I think it is not much
>> work to generate the other concrete classes when the abstract and
>> first concrete class are finished.
>>
> That's a bit optimistic. JDBC as a standard is a little vague,

Better than most database API's. I really like the capabilities
in the DatabaseMetaData.

>                                                               and 
> surprising things can happen, starting with your mapping from database 
> types to Java SQL types (NUMERIC?, REAL?, DECIMAL?... - and this can 
> change even when updating from version of a driver to another of the 
> same vendor).

????

JDBC defines mapping for standard types.

NUMERIC and DECIMAL maps to BigDecimal.

REAL maps to float or Float depending on context.

>       Then there are the peculiarities of caching, dealing with 
> cursors, how to write your queries they are optimized etc.

Portable code can not always be max optimized.

Arne

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

#37260

Am 17.08.2017 um 03:21 schrieb Arne Vajhøj:
> On 8/13/2017 4:24 PM, Sebastian wrote:
[snip]
>>                                                               and
>> surprising things can happen, starting with your mapping from database
>> types to Java SQL types (NUMERIC?, REAL?, DECIMAL?... - and this can
>> change even when updating from version of a driver to another of the
>> same vendor).
>
> ????
>
> JDBC defines mapping for standard types.
>
> NUMERIC and DECIMAL maps to BigDecimal.
>
> REAL maps to float or Float depending on context.
[snip]

I did not mean that mapping, but the step before it, concerning 
metadata: the mapping of database types (what you put in the CREATE 
TABLE statement to define the columns) to standard types, i. e. 
constants in java.sql.Types. With Oracle, you may get a description of 
all supported data types with DatabaseMetadata.getTypeInfo(), or call 
DatabaseMetadata.getColumns() on a table.

Case in point: When Oracle updated the JDBC driver from 12.1.0.1 to 
12.1.0.2 (in ojdbc7) they did some changes and some bug-fixing, and my 
metadata-dependent code was bitten by the driver suddenly returning 
NUMERIC instead of DECIMAL for some NUMBER columns and NVARCHAR instead 
of OTHER for NVARCHAR2 columns. (The code wasn't any good in the first 
place, let's not argue about that...) Along came 12.2.0.1 (ojdbc8) , and 
I was happy it behaved the same way as 12.1.0.2, but still I had had to 
write all those automatic regression tests.

Metadata is one of the areas where there's little standardization, and 
drivers from different vendors differ to a greater extent. In part this 
is understandable, because the type inventories differ so much. But even 
when types are practically identical between vendors, you may get 
different metadata. For example, in SQL Server DECIMAL and NUMERIC are 
synonymous in the database, but still they chose to map them to the two 
respective Types constants (which have no such synonymity assumption) 
instead of choosing the same target for both. In some other databases, 
java.sql.Types.NUMERIC is mapped from some integer type.

Sorry for the lengthy clarification. I'd like to avoid to get 
side-tracked in this thread. I just wanted to point out one possible 
pitfall in designing a vendor-independent layer above JDBC.

-- Sebastian

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

#37263

On 8/17/2017 5:33 PM, Sebastian wrote:
> Am 17.08.2017 um 03:21 schrieb Arne Vajhøj:
>> On 8/13/2017 4:24 PM, Sebastian wrote:
>>>                                                               and
>>> surprising things can happen, starting with your mapping from database
>>> types to Java SQL types (NUMERIC?, REAL?, DECIMAL?... - and this can
>>> change even when updating from version of a driver to another of the
>>> same vendor).
>>
>> ????
>>
>> JDBC defines mapping for standard types.
>>
>> NUMERIC and DECIMAL maps to BigDecimal.
>>
>> REAL maps to float or Float depending on context.

> I did not mean that mapping, but the step before it, concerning 
> metadata: the mapping of database types (what you put in the CREATE 
> TABLE statement to define the columns) to standard types, i. e. 
> constants in java.sql.Types. With Oracle, you may get a description of 
> all supported data types with DatabaseMetadata.getTypeInfo(), or call 
> DatabaseMetadata.getColumns() on a table.

> Metadata is one of the areas where there's little standardization, and 
> drivers from different vendors differ to a greater extent. In part this 
> is understandable, because the type inventories differ so much. But even 
> when types are practically identical between vendors, you may get 
> different metadata. For example, in SQL Server DECIMAL and NUMERIC are 
> synonymous in the database, but still they chose to map them to the two 
> respective Types constants (which have no such synonymity assumption) 
> instead of choosing the same target for both. In some other databases, 
> java.sql.Types.NUMERIC is mapped from some integer type.
> 
> Sorry for the lengthy clarification. I'd like to avoid to get 
> side-tracked in this thread. I just wanted to point out one possible 
> pitfall in designing a vendor-independent layer above JDBC.

Ah.

Yes - DDL or code that use DDL data are probably not very portable.

Arne

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

#37205

Cecil Westerhof <Cecil@decebal.nl> writes:

> Robert Klemme <shortcutter@googlemail.com> writes:
>
>> Another aspect of the original question that puzzled me right from the
>> start: why does it matter at all what JDBC driver is really used.  Since
>> all the types are interfaces anyway _any_ JDBC driver should work with
>> the wrapper library (except vendor specific things which require
>> specific types anyway).
>
> The only things that differs (as long as you only use generic
> functionality) is the URLPrefix. That is why I think it is not much
> work to generate the other concrete classes when the abstract and
> first concrete class are finished.

I think that everything that is needed to generate a new concrete
class is:
    package nl.decebal.sql;


    import java.sql.SQLException;


    public class SQLFoo extends AbstractSQL {
        // ################ main
        public static void main(final String[] args) throws SQLException {
            AbstractSQL.mainWork(SQLFoo.class.getCanonicalName(), args);
        }

        // ################ constructors
        public SQLFoo(String database) throws SQLException {
            super(database);
        }

        // ################ default
        @Override
        String getURLPrefix() {
            return "jdbc:foo:";
        }
    }

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

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

#37220

On 13.08.2017 23:24, Cecil Westerhof wrote:
> Cecil Westerhof <Cecil@decebal.nl> writes:
> 
>> Robert Klemme <shortcutter@googlemail.com> writes:
>>
>>> Another aspect of the original question that puzzled me right from the
>>> start: why does it matter at all what JDBC driver is really used.  Since
>>> all the types are interfaces anyway _any_ JDBC driver should work with
>>> the wrapper library (except vendor specific things which require
>>> specific types anyway).
>>
>> The only things that differs (as long as you only use generic
>> functionality) is the URLPrefix. That is why I think it is not much
>> work to generate the other concrete classes when the abstract and
>> first concrete class are finished.
> 
> I think that everything that is needed to generate a new concrete
> class is:
>      package nl.decebal.sql;
> 
> 
>      import java.sql.SQLException;
> 
> 
>      public class SQLFoo extends AbstractSQL {
>          // ################ main
>          public static void main(final String[] args) throws SQLException {
>              AbstractSQL.mainWork(SQLFoo.class.getCanonicalName(), args);
>          }
> 
>          // ################ constructors
>          public SQLFoo(String database) throws SQLException {
>              super(database);
>          }
> 
>          // ################ default
>          @Override
>          String getURLPrefix() {
>              return "jdbc:foo:";
>          }
>      }
> 

But why tie your code to concrete JDBC implementations at all, 
especially since you do not seem to want to create custom code for 
individual JDBC drivers?  Why not just pass in the class name, JDBC URL 
and other properties which are needed during initialization and free 
yourself from any dependency?

Cheers

	robert

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

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

#37227

Robert Klemme <shortcutter@googlemail.com> writes:

> But why tie your code to concrete JDBC implementations at all,
> especially since you do not seem to want to create custom code for
> individual JDBC drivers?  Why not just pass in the class name, JDBC URL
> and other properties which are needed during initialization and free
> yourself from any dependency?

That is a great idea. I should make the abstract class concrete: then
this could be used for databases where there is no implementation for
yet.

I did make custom code for the SQLite3 implementation. I do not know
if the others need custom code yet.

For example I have the following in my cron:
    java -cp ${_classpath} nl.decebal.sql.SQLite3 --areDBsLocked ${_databases[*]}

To verify that about 20 different databases are not locked. In SQLite3
only one program can have an active connection to a database. And if
you have a databasebrowser open and forgot to do a `Write Changes’
other programs get a locked database.

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

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

#37193

Am 13.08.2017 um 20:30 schrieb Robert Klemme:
> On 13.08.2017 18:08, Sebastian wrote:
[snip]
>>
>> Back to the original question: In 15 years of development work for
>> midle to large sized companies I have never seen an open source
>> database used in the production environment, it's mostly Oracle,
>> SQLServer, and DB2, with the single exception of PostgreSQL.
>
> Now I'm confused: did you see an OSS DB in production - or not? :-)
>
Yes, PostgreSQL, once. It was installed alongside some commercial 
product that required it for its user management.
-- Sebastian

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

#37200

On 8/13/2017 2:30 PM, Robert Klemme wrote:
> Another aspect of the original question that puzzled me right from the
> start: why does it matter at all what JDBC driver is really used.  Since
> all the types are interfaces anyway _any_ JDBC driver should work with
> the wrapper library (except vendor specific things which require
> specific types anyway).

There are two ways to handle the database specific stuff:
A) Sub-typing
B) Utilizing the builtin stuff in JDBC like DatabaseMetaData and
    escape syntax

#A is common but #B is severely underutilized in my opinion!

Arne

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

#37206

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

> On 8/13/2017 2:30 PM, Robert Klemme wrote:
>> Another aspect of the original question that puzzled me right from the
>> start: why does it matter at all what JDBC driver is really used.  Since
>> all the types are interfaces anyway _any_ JDBC driver should work with
>> the wrapper library (except vendor specific things which require
>> specific types anyway).
>
> There are two ways to handle the database specific stuff:
> A) Sub-typing
> B) Utilizing the builtin stuff in JDBC like DatabaseMetaData and
>    escape syntax
>
> #A is common but #B is severely underutilized in my opinion!

Can you point me to resources where I can learn about that?

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

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

#37217

On 8/13/2017 5:35 PM, Cecil Westerhof wrote:
> Arne Vajhøj <arne@vajhoej.dk> writes:
>> On 8/13/2017 2:30 PM, Robert Klemme wrote:
>>> Another aspect of the original question that puzzled me right from the
>>> start: why does it matter at all what JDBC driver is really used.  Since
>>> all the types are interfaces anyway _any_ JDBC driver should work with
>>> the wrapper library (except vendor specific things which require
>>> specific types anyway).
>>
>> There are two ways to handle the database specific stuff:
>> A) Sub-typing
>> B) Utilizing the builtin stuff in JDBC like DatabaseMetaData and
>>    escape syntax
>>
>> #A is common but #B is severely underutilized in my opinion!
>
> Can you point me to resources where I can learn about that?

I think you already found DatabaseMetaData class documentation.

Escape syntax is actually more tricky to find general information about.

Some googling found:

https://docs.oracle.com/javase/1.5.0/docs/guide/jdbc/getstart/statement.html#1006519

Arne

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

#37218

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

> On 8/13/2017 5:35 PM, Cecil Westerhof wrote:
>> Arne Vajhøj <arne@vajhoej.dk> writes:
>>> On 8/13/2017 2:30 PM, Robert Klemme wrote:
>>>> Another aspect of the original question that puzzled me right from the
>>>> start: why does it matter at all what JDBC driver is really used.  Since
>>>> all the types are interfaces anyway _any_ JDBC driver should work with
>>>> the wrapper library (except vendor specific things which require
>>>> specific types anyway).
>>>
>>> There are two ways to handle the database specific stuff:
>>> A) Sub-typing
>>> B) Utilizing the builtin stuff in JDBC like DatabaseMetaData and
>>>    escape syntax
>>>
>>> #A is common but #B is severely underutilized in my opinion!
>>
>> Can you point me to resources where I can learn about that?
>
> I think you already found DatabaseMetaData class documentation.
>
> Escape syntax is actually more tricky to find general information about.
>
> Some googling found:
>
> https://docs.oracle.com/javase/1.5.0/docs/guide/jdbc/getstart/statement.html#1006519

Thanks, I will look into it.

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

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

#37199

On 8/13/2017 12:08 PM, Sebastian wrote:
> Back to the original question: In 15 years of development work for midle
> to large sized companies I have never seen an open source database used
> in the production environment, it's mostly Oracle, SQLServer, and DB2,
> with the single exception of PostgreSQL.

There are also sites that use MySQL in production.

But database tier is probably the tier where there is most focus on
support.

Arne

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

#37207

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

> On 8/13/2017 12:08 PM, Sebastian wrote:
>> Back to the original question: In 15 years of development work for midle
>> to large sized companies I have never seen an open source database used
>> in the production environment, it's mostly Oracle, SQLServer, and DB2,
>> with the single exception of PostgreSQL.
>
> There are also sites that use MySQL in production.

I understood that H2 is also used at a lot of places.

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

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

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

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

csiph-web