this flags specifies that if a #GdaMetaStore has been associated to the connection, then it is kept up to date with the evolutions in the database's structure. Be aware however that there are some drawbacks explained below.
no specific aspect
this flag specifies that the connection to open should be in a read-only mode (this policy is not correctly enforced at the moment)
this flag specifies that SQL identifiers submitted as input to Libgda have to keep their case sensitivity.
this flag specifies that the connection to open will be used by several threads at once and requests that the real connection be used only in a sub thread created specifically for it
this flag specifies that the connection to open will be used by several threads at once so it has to be thread safe
Specifies some aspects of a connection when opening it.
Additional information about the GDA_CONNECTION_OPTIONS_SQL_IDENTIFIERS_CASE_SENSITIVE flag:
For example without this flag, if the table
name specified in a #GdaServerOperation to create a table is
MyTable , then usually the database will create a table named
mytable , whereas with this flag, the table will be created
as MyTable (note that in the end the database may still decide
to name the table mytable or differently if it can't do
otherwise). Libgda will not apply this rule when parsing SQL code, the SQL code being parsed
has to be conform to the database it will be used with
Additional information about the GDA_CONNECTION_OPTIONS_THREAD_SAFE and GDA_CONNECTION_OPTIONS_THREAD_ISOLATED flags: The GDA_CONNECTION_OPTIONS_THREAD_SAFE flag specifies that it has to be able to use the returned connection object from several threads at once (locking is ensured by the #GdaConnection itself). Depending on the database provider's implementation and on the native libraries it uses, the "normal" connection object might not respect this requirement, and in this case a specific thread is started and used as the unique thread which will manipulate the actual connection, while a "wrapper connection" is actually returned and used by the caller (that wrapper connection passes method calls from the calling thread to the actual connection's specific thread, and gets the results back).
The GDA_CONNECTION_OPTIONS_THREAD_ISOLATED forces using a specific thread and a "wrapper connection" even if the "normal" connection would itself be thread safe; this is useful for example to be sure the asynchronous API can always be used (see gda_connection_async_statement_execute()).
Having a specific thread and a "wrapper connection" definitely has an impact on the performances (because it involves messages passing between threads for every method call), so using the GDA_CONNECTION_OPTIONS_THREAD_SAFE or GDA_CONNECTION_OPTIONS_THREAD_ISOLATED flags should be carefully considered.
Note about the
Every time a DDL statement is successfully executed, the associated meta data, if
defined, will be updated, which has a impact on performances If a transaction is started and some DDL statements are executed and the transaction
is not rolled back or committed, then the meta data may end up being wrong
GDA_CONNECTION_OPTIONS_AUTO_META_DATAflag: