Re: [gnome-db] gda_column_get_primary_key()

2008/11/20 Murray Cumming <murrayc murrayc com>
On Thu, 2008-11-20 at 15:26 +0100, Vivien Malerba wrote:
> 2008/11/20 Johannes Schmid <jhs jsschmid de>
>         Hi!
>         > In V3 the information was available using the GdaDict
>         object. In V4,
>         > the same information is available using the GdaMetaStruct
>         object.
>         >
>         > The only difference (appart from the API) is that in V3 all
>         the
>         > dictionary had to be in memory all the time even if not used
>         whereas
>         > in V4 only the requested part of the dictionary is loaded in
>         memory:
>         > the dictionary itself is represented by a GdaMetaStore
>         (which uses a
>         > DB) and an extract of the dictionary is represented as a
>         > GdaMetaStruct.
>         Could you give me some example then how to replace
>         gda_column_set_primary_key() in V4? I have checked the API of
>         GdaMetaStore and GdaMetaStruct but it's not obvious to me how
>         that
>         should work.
> gda_column_set_primary_key() only positionned a boolean to TRUE. If
> what you need is to set a boolean and then later test that boolean,
> you can use the g_object_set/get_data() as a replacement.
> If you are talking about gda_column_get_primary_key(), to obtain
> information about a table's column, then you can have a look at the
> example at
> You can also have a look at the
> set_column_properties_from_select_stmt() function in the
> gda-data-select.c which determines some attributes for the columns of
> a data model resulting of the execution of a SELECT statement.

I still don't understand. Is the "this field is a primary key"
information something that is stored in the server (PostgreSQL in this
case) or not?

The default is, as for V3, that Libgda creates its own dictionary file (in V3 it was an XML file, and in V4 it's an SQLite DB file). This can be changed and it's possible to store the meta data in the database being accessed. See for some example.

Compared to the V3, using a database to store the meta data has the following benefits:
* the data does need to be in memory at all times => more meta data types can be handled (indexes, triggers,...) at almost no cost
* the Libgda's user can more easilly store his own data within in that database (it's like a normal GdaConnection with a small helper API). For example the gda-sql-4.0 console tool stores some user-defined SQL statements



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]