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 bugzilla.gnome.org (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
set.
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
backend.
I'm sure Gonzalo will appreciate the SQL statements you talk about.
Gonzalo?
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
MySQL.
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
code.
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.
cheers
