ADBA feedback

[Douglas Surber]

I definitely see your point.

Index based access (and SELECT *) are maintenance nightmares. If we must have index based access how about something like this:

  /**
   * Return the value of the nth occurrence of an out parameter or select value identified by id.
   */
  public <T> T get(String id, int n, Class<T> type);

Just a thought.

Douglas

> On Apr 27, 2018, at 8:26 AM, Lukas Eder <lukas.eder at gmail.com> wrote:
> 
> 
> 
> 2018-04-27 16:57 GMT+02:00 Douglas Surber <douglas.surber at oracle.com <mailto:douglas.surber at oracle.com>>:
> As all ADBA apps will be new ...
> 
> Not all apps might be new. Some might be migrated, meaning migrations of JDBC to ADBA might be risky. That can be OK, but I guess there should be a known limitations page to make this warning, in that case.
>  
> ... the programmer will have the opportunity to modify the SQL to eliminate duplicate column labels. 
> 
> How about
> SELECT * FROM t, t
> 
> Sure, they can fix the query with aliasing, but both t's have 500 columns, and business really needs the cross product. :-)
> 
> Of course, a more real world scenario is a query like
> SELECT * FROM a JOIN b ON something
> 
> Where a and b share column names - e.g. say FIRST_NAME, LAST_NAME, but the SELECT * query is just too convenient and we actually need to project all the 100 columns. My concern here would be that a user might read the wrong column for subtle reasons. Especially if the join is added later on and the duplication of column names is accidental.
> 
> Now, languages like PL/SQL can handle both.
> 
> Index-based (works):
> 
> SELECT 1 a, 1 a
> INTO a1, a2
> FROM dual;
> 
> Name-based (fails):
> 
> FOR rec IN (SELECT 1 a, 1 a FROM dual) LOOP
>   NULL;
> END LOOP;
> 
> The latter fails with an error because of ambiguous column names. Perhaps that would be a solution here, to specify that ADBA implementations must fail on such an ambiguity (even if there's no such spec in JDBC).
>  
> I prefer to omit index based access for now. I think it hurts readability and rationally we shouldn’t use it but we are all in the habit of using it. I would like to see if we can break that habit. Maybe it really is necessary in which case we can add it in version 2 or 3 or whatever.
> 
> Perhaps. It can definitely be added later on.