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

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

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


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