Re: [gnome-db] Re: Feature requests to get gnome-db working with bonddb

Rodrigo Moya wrote:

On Fri, 2002-05-10 at 03:06, Andrew Hill wrote:
For every field in the database I need to know what the data type it is. This doesn't need to be detailed, just to know if its interger, float, text, if got character limit.

yes, everything is available, except the character limit.

char limit not essential, just next time your working on that code oh yeah
char limit.

ok, it would help if you add bugs to (libgda
product), so that I keep track easily of all the feature requests.

Comments: (nessesary)

Comments can be put onto fields, tables etc in postgresql. Certain information about
relationships are stored sometimes in comments on fields.

right now, we can retrieve this by using the schemas. We could move that
to be included in GdaFieldAttributes, which is what providers return to
clients when these ask them to describe a column.

It'll be best if it was in the attributes. I only use comments put on fields,
though consivable i might one day use comments on tables.  it'll
be awfully handy if it was added into the GdaField class.

ok. Some providers won't be able to get them, but hey, that's enough if
the ones that can actually do it.

Constraints set up (critical)

This is the real imporant one, in knowing what forign keys are there, and what relationships they are. This information is in the form of this table and fieldname refer to this table and
fieldname in a one to many relationship.

I've added the basic beginning for this, which is just the API for
setting/getting this on the rows/tables/etc. Missing is setting this
info in the providers, and extend the set of information providers can

Getting is the more important one.  For postgresql I had a class with
a source table and field, and a destination table and field, and relationship type. But been able to set in gda would be great for getting around shortcoming of
providers, if provider did't provide that support you could store the
relationships seperately for info just for gnome-db.

please, add a bug about it, since it needs a bit of thinking.

Unquie IDs (critical)

In postgresql I use the oid to access unqiue records internally to bonddb. Oid is a postgresql thing, though oracle has it to. I've re-written my code to add support for using the primary keys on a table instead of oids. Knowing what fields in a table are primary keys would be very useful. So knowing the property of a field, and seeing if it is a primary key would solve this.

also, I've added a gda_row_set/get_id functions, so that providers, when
they return a row, can set a unique ID on that row. Thus, the client can
reference that unique ID on later operations. Again, providers don't set
this yet, but they will soon.

How does it work?
Do you store an additional id in the table? or work out what the id is?

work out what the id id. PostgreSQL, for instance, will use the OIDs,
Oracle ROWID's, etc. Others may just use a key to identify the primary
key of that row, etc

what if mulitple keys make hte unique id?  Would it be easier
adding a attribute primary_key to the field attributes.

primary_key is already in the field attributes. But we also need to
support primary keys composed of several fields, which is also something
a lot of people use. So, the field attributes have the primary_key
field, but we also need to identify each row. Of course, if only one
field is primary_key in a table, the app can assume that's the primary
key and use that for later commands.

Field default value (nessesary)

There is two parts to this, first is knowing the default value set to a field, and the second is if that default value comes from a function. Ie if there is a default value, and it gets that default value from calling a function, whats the name of the function so i can not call it.
For example if the default value is set to todays date (by a function).

not available, but we'll add it.

please, add a bug, or I will forget it :-)

Unique ID of a added record (nessesary)

When you do an insert into postgresql it returns the oid of the newly inserted record. I need to run sql statements on a record just entered, and if things like the primary key are serial or random values set on insert I need to know those values when it inserts so I can reaccess that record. In postgresql provider returning the oid is fine. For other databases I can work around the problem with a solution of assign all the primary keys a value on insert and dont let anything be assigned by the database.
once all providers set a unique ID on all rows, we can easily have them
return that ID of the inserted record. Let me think a bit more about
this, since I think we can do all of this in the data models, for which
I've added a begin_edit/cancel_edit/end_edit set of functions, and I
plan on adding a new gda_data_model_append_row, which can then return
the ID of the inserted record.

lol. your addeding bonddb functionalilty to your code. If i know what the primary keys are and what there default values, and default functions I can set all this
on write so in the SQL statement i send.

well, the difference is that we have to support non-SQL scenarios. You
use SQL for PostgreSQL, which is fine, but this stuff I'm adding is
about having editable data models. Each provider will do whatever it
needs to internally (prepare SQL command), but the libgda API must be
SQL-independent in this stuff.

Views (not essential)

I need a list of all the views in the database, and the SQL statement that was used to create the view. I use views to define extra contraint information and define
certain types of relationships.

it's already available.

sweet. whats the function/attributes wher ei can get a list of views.

gda_connection_get_schema, with the GDA_CONNECTION_SCHEMA_VIEWS.

We implimented gnome-db into bonddb so it now uses it. But it dies real
quick when it comes to running it because it doesn't know what the
primary keys are. I can get to work on a basic class object doing some of the simiple
functions if I know what fields are primary keys are in a table.
And then th next set would be default values so I could add data to the
database. After that constraints so I can build up proper class objects. From there it should be just a matter of tidying up the others to get the non-essentail
functions working.  I have some SQL statements for getting approrpirate data
from postgresql if that would help the postgresql provider. The easiest way
for me to do testing is to get the postgresql provider working with these
new functions and then testing the results set against my native postgresql

I'm sure Gonzalo will appreciate the SQL statements you talk about.

Another useful feature, which I havn't fully implimented in my code but would be nice, is knowing what functions arn't and are supported by the provider your using.
hmm, the postgres provider just returns the list of procs that the user
can use, AFAIK. We could do that in all providers.

And another thing, do you have a function like gda_connection_new_from_dsn
where you can pass in a single string describing all the connection information?

no, but I'll add it very quicky if you add a bug, since I'll look at my
bug list tonight, and as it's easy, I'll get it and fix it :-)

So its easy to specify host, if secure or not, username, password etc in one command.
is there a way to specify the host your connecting to?

yes, HOST=host in the connection string, at least for PostgreSQL and

Does gda_export_get_tables return a list of all tables? should i be using that or something
else to get a list of all tables.

you can use that, but that's not the proposed way. You should be using
gda_connection_get_schema, which lets you get information about the
objects in the database (tables, functions, views, etc)

Do you know if that gnome-cvs account is set up yet? I should try checking in some

no idea. It usually takes looooong :-(

Please add bugs for all feature requests. Thus, not only me, but also
people wanting to help can pick a task.


Is primarykey already in the field attributes class? I'll get those bugs into bugzilla.

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