ADBA feedback

[Lukas Eder]

2018-04-27 16:57 GMT+02:00 Douglas Surber <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.