GNOME Bugzilla – Bug 589607
gda_connection_get_meta_store_data(GDA_CONNECTION_META_FIELDS) fails with uppercase table name
Last modified: 2009-07-27 13:01:08 UTC
The attachement shows that gda_connection_get_meta_store_data() fails with GDA_CONNECTION_META_FIELDS with a table name such as "CapitalTest", even when using the GDA_CONNECTION_OPTIONS_SQL_IDENTIFIERS_CASE_SENSITIVE connection option. The test creates a table, then updates and shows the metadata, then tries to get the fields list. It fails for both PostgreSQL and SQLite.
Created attachment 139153 [details] gda-metastore-capital-letters-fields.c Fails for "CapitalTest". Succeeds for "lowercasetest".
Created attachment 139174 [details] Modified test case with gda_meta_store_sql_identifier_quote() added You need to pass an SQL identifier which conforms to the "GdaMetaStore convention", which means using gda_meta_store_sql_identifier_quote(), or gda_sql_identifier_quote() directly. See my modified version of the attachment. There was also some bug in the meta data retreival with SQLite, which I've corrected and pushed in master and LIBGDA_4.0.
Thanks. I thought that the connection option made that unnecessary too. This is only for the meta store API, right? What's the reasoning for requiring these input parameters to be modified like this? Why can't libgda just take the normal name string and do what it likes with it?
Making sure the SQL identifiers as input to any meta store API respects the GdaMetaStore convention is a necessity because the SQL identifier used can come from either the user which created an object like in the test case, or from the GdaMetaStore itself where it already is in the correct convention representation.
This indeed seems to be fixed now. Thanks. Now I hit bug #589822 instead.
How(In reply to comment #4) > Making sure the SQL identifiers as input to any meta store API respects the > GdaMetaStore convention is a necessity because the SQL identifier used can come > from either the user which created an object like in the test case, or from the > GdaMetaStore itself where it already is in the correct convention > representation. However, this leaks an internal data structure (the GdaMetaStore name convention) to the public API. I guess you need: - a public API (that just takes names) and - an internal API (that takes names already in the internal format, without the need for any conversion) for performance.
> However, this leaks an internal data structure (the GdaMetaStore name > convention) to the public API. When one obtains data from a meta store, it is obtained using that convention and one may use that input (which is in the GdaMetaStore name convention), so the public API really can be used with SQL identifiers which are already in the meta store convention.
(In reply to comment #7) > > However, this leaks an internal data structure (the GdaMetaStore name > > convention) to the public API. > > When one obtains data from a meta store, it is obtained using that convention Yes, I don't like that either. It again leaks the internal representation. I hope that the meta-store API can be corrected in a future libgda version.