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

[Rodrigo Moya <rodrigo gnome-db org>]

On Thu, 2002-05-09 at 03:11, Andrew Hill wrote:
> Hello people
> I've got some feature requests.  I'll try to be general, and I will no 
> doubt include items that
> gnome-db already does.  I've specified how important features are to 
> base functionality
> of bonddb. These arn't possible in all sql databases, but if they arn't 
> it would be good if gnome-db could respond as such (ie feature not 
> supported in provider).
> 
> Information about fields:
> 
> Field Types: (not essential)
> 
that's already present, and one of the thins I like the most, since
we've got a lot of custom types, and providers just convert their
internal types to those.

If we need more types, it's just a matter of adding support for them, as
did Gonzalo for the GeometricPoint type, used in PostgreSQL

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> Functions (not at all essential)
> 
> A list of functions in the system, and the contents of there functions.
> I use this a bit in postgresql but its hardly essential to me.  
> 
also available.

> 
> Anyway this will really help me if we can get some of these implimented. 
>  Or at least
> take these into future design considerations.
> 
we'll take all of them into consideration. I'd appreciate if you could
give more detailed suggestions. That is, please start using libgda, and
tell me how/where you'd need the specific features.

I am myself working now on having the data models editable, which will
solve the unique IDs problems and, of course, let us modify the database
without having to issue any SQL command (the SQL will be executed
internally by the providers).

cheers