GNOME.org
 

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

Rodrigo Moya wrote:


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


Nope internal types is fine.
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.




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.


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.


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?
what if mulitple keys make hte unique id?  Would it be easier
adding a attribute primary_key to the field attributes.


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


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.




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.


yah
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


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.
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. 
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? 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?
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.
Do you know if that gnome-cvs account is set up yet? I should try checking in some 
code.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]