Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Which databases are the most used with Java Date: Sun, 13 Aug 2017 20:00:40 -0000 (UTC) Organization: A noiseless patient Spider Lines: 90 Message-ID: References: <87y3qovwjb.fsf@munus.decebal.nl> <87tw1bx2c9.fsf@munus.decebal.nl> <87a833wzcx.fsf@munus.decebal.nl> <87pobz9yv5.fsf@munus.decebal.nl> <87d17zs1sx.fsf@munus.decebal.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sun, 13 Aug 2017 20:00:40 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="70f7f9b9062e6e503a07259b35ef79a7"; logging-data="2247"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+SURq+FzrS0nqRwmV/BJo7hTK6fR9xstA=" User-Agent: Pan/0.141 (Tarzan's Death; 168b179 git.gnome.org/pan2) Cancel-Lock: sha1:nX+mtGNqXhVCUhv2DyA/hdZhyfk= Xref: csiph.com comp.lang.java.programmer:37192 On Sun, 13 Aug 2017 21:30:38 +0200, Cecil Westerhof wrote: > Robert Klemme writes: > >> On 13.08.2017 19:11, Cecil Westerhof wrote: >>> Robert Klemme writes: >>> >>>> On 13.08.2017 12:12, Cecil Westerhof wrote: >>>>> Andreas Leitgeb 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 |