tdbc::sqlite3

View Ticket
Login
Ticket Hash: 8d015d929f6294e2f77e7c580cb86e182f5508b5
Title: tdbc::sqlite3 driver doesn't resolve duplicate names
Status: Deferred Type: Code_Defect
Severity: Important Priority: Medium
Subsystem: tdbc::sqlite3 Resolution: Open
Last Modified: 2019-09-13 17:15:05
Version Found In: 1.0b13
Description:
When doing a join on tables whaving columns with same name like this:
select a.name, b.name from t1 a, t2 b where a.id = b.id;

the tdbc::sqlite driver will only return one 'name' key in a result dict. A result list will contain both values, but the columnvariable will contain the same column name twice.


kbk added on 2009-10-27 01:09:56:
This is being recorded as a 'known bug'. It's essentially unfixable until we convert the SQLite3 driver over to using C, because that's where it's tripping over the duplicate names.


kbk added on 2009-10-27 01:10:40:
Oh, yeah. It can be fixed by using AS clauses to disambiguate the column names.

User Comments:
anonymous added on 2019-08-31 15:07:14:
I'm not sure that disambiguating works, or I don't know how to make it work.

I'm using tdbc::sqlite3 1.1.0 on Linux Mint.

I hope to attach a test program that seeks to set up tables of Premier League teams and fixtures, populate them with this weekend's fixtures. The attached log
shows that a query to display a fixture list works ok when executed directly through the sqlite3 utility but fails when executed through tdbc, displaying the home team's name twice.

kbk added on 2019-09-13 17:15:05:
You give as example the query:

    SELECT
        fix_date,
        home.tea_name,
        away.tea_name
    FROM
    fixtures
    JOIN
    teams AS home ON home.tea_id = fix_home
    JOIN
    teams AS away ON away.tea_id = fix_away

The way to work around it is to make sure that all the column names returned are distinct.

  SELECT fix_date, home.tea_name AS hometeam, away.tea_name AS awayteam
  FROM fixtures
  JOIN teams AS home ON home.tea_id = fix_home
  JOIN teams AS away ON away.tea_id = fix_away

Now you don't have a name collision and you won't have a problem with one 'tea_name' overwriting another.

Attachments: