This bug will be corrected once the new parser and statement infrastructure will be available.

Another note I discovered:

running this query without the GROUP BY statement doesn't output nothing.
SELECT symbol.symbol_id, symbol.name, symbol.file_position, symbol.is_file_scope, symbol.signature, sym_kind.kind_name  FROM symbol  JOIN sym_kind ON symbol.kind_id = sym_kind.sym_kind_id WHERE symbol.is_file_scope = 0 AND sym_kind.kind_name IN ('class') 


while this outputs correct results.
SELECT symbol.symbol_id, symbol.name, symbol.file_position, symbol.is_file_scope, symbol.signature, sym_kind.kind_name  FROM symbol  JOIN sym_kind ON symbol.kind_id = sym_kind.sym_kind_id WHERE symbol.is_file_scope = 0 AND sym_kind.kind_name IN ('class') GROUP BY symbol.name

I saw you added a new parsing mechanism on svn. Is it already usable or does it need improvements?

thanks and regards,
Massimo

It should be useable and work correctly at least on the SQLite provider.

malerba, What version (tarball?) should he try to confirm that this is fixed?

The trunk version (after V4-branch merge) has this fixed.

Massimmo, it would be great if you could confirm that this is now fixed.

With libgda v 4.x it's fixed, but probably there's a minor issue left.

Take for example this query:

SELECT symbol.symbol_id, symbol.name, symbol.file_position, symbol.is_file_scope ,
symbol.signature, sym_kind.kind_name FROM symbol 
      JOIN sym_kind ON symbol.kind_id = sym_kind.sym_kind_id 
      WHERE symbol.scope_id <= 0 AND symbol.is_file_scope

using gda_data_model_dump (data, stdout); I get something like:

symbol.symbol_id | symbol.name             | symbol.file_position | symbol.is_file_scope | symbol.signature | sym_kind.kind_name | sym_kind.access_name
----------+------------------+---------------+---------------+-----------+-----------+------------
      356 | Build            |            34 |             0 |           | namespace |            
      669 | Commander        |            34 |             0 |           | namespace | 

I was expecting to be able to retrieve the different fields' values with something like

gda_data_model_iter_get_value_for_field (priv->data_iter, "kind_name");

without specifing the exact "sym_kind.kind_name" field. I'm not using prepared statements for this query, just a simple  gda_connection_statement_execute_select (). As now I fixed that "bug" (?) with a query like


SELECT symbol.symbol_id AS symbol_id, symbol.name AS name, symbol.file_position AS file_position, symbol.is_file_scope AS is_file_scope,
symbol.signature AS signature, sym_kind.kind_name AS kind_name FROM symbol 
      JOIN sym_kind ON symbol.kind_id = sym_kind.sym_kind_id 
      WHERE symbol.scope_id <= 0 AND symbol.is_file_scope


but I don't think that's really correct nor that I need that aliasing. There are no conflicting fields names between different tables.


thanks and regards,
Massimo

I've just tried to make this query prepared

SELECT symbol.symbol_id, symbol.name, symbol.file_position,
symbol.is_file_scope ,
symbol.signature, sym_kind.kind_name FROM symbol 
      JOIN sym_kind ON symbol.kind_id = sym_kind.sym_kind_id 
      WHERE symbol.scope_id <= 0 AND symbol.is_file_scope

and I'm able to retrieve the fields just specifying the field as "kind_name".

When executing a SELECT statement, the column names of the returned GdaDataModel are the ones returned by the DBMS's API. In any way I would recommend against using column names to find a column as nothing guarantees that column names will be unique; it's better to use column numbers (even though it has its drawbacks as well).

Of course it would still be possible to override the column names in a generic way but I can't think of a correct algorythm which would ensure unique column names and still use real column names when possible. Any idea?

Well, I thought it was libgda that had to take care of the naming of the columns.
Probably, but this is just an idea that may not work at all, the columns returned can be named as "tablename"_"columnname", with the "_" that concatenates the two strings and make unique the result.

Anyway I solved the problem specifying an alias for every column name, say 
"select field1 AS my_foo_field from ...".
With a prepared statement that works good without speed problems...

thanks and regards,
Massimo

ps: I think you can close this bug.

Ok closing the bug. If you have a proposal for a better fields naming, then please fill another bug.
Thanks, Vivien