Re: [gtk-list] GNOME Database kit



>>>>> "ak" == Adam Keys <adam@pingpage.com>
>>>>> wrote the following on Wed, 05 Aug 1998 13:31:40 -0500

ak> Elliot Lee wrote:
>> 
>> On Wed, 5 Aug 1998, Adam Keys wrote:
>> 
>> > I've seen various database utilities floating around, like the one Dr.
>> > Mike of RHAD is working on.  I'm into the database stuff and want to
>> > write a really cool database library for GNOME.  I want it to be
>> > portable, abstracted, and powerful.
>> > I'm looking for other database gurus and some gtk gurus to create the
>> > widgets needed to logically interact with a database.  Attacted is a
>> > little white paper scrap I wrote up outlining the intent of the kit.
>> 
>> Are you wanting to create a standard database API, or a standard way of
>> displaying results, or what?
>> 

ak> I want to create an API that abstracts the connection and capabilites of
ak> the database.  A code example in c++

ak> Connection conn = new mysqlConnector( "host", "user", "passwd" );

ak> Results res = conn.execute( "select * from table" );

ak> and from there you could feed the Result to a widget that can display
ak> the results in a spreadsheet-like table.  The widgets would more or less
ak> be a part of the API, since primary use would be for working with
ak> databases.

I don't want to use C++ for this. Gnome applications are written in
C. It's hard to call C++ from C programs. It's easy to call C
from C++ programs. And it can all be done with dynamic loading and a
table of function pointers. 

I 've written something like this before in C++ and i must say, that
inheritance was almost never used. Code reuse is possible (data types
like database_row, database_result_set, column_description and related 
functions) but this can be done with C also.



>> Have you looked at the ODBC API yet? It is much more mature, it does what
>> we need, and it is an industry standard...
ak> The problem so far as I see is that ODBC drivers must be written and
ak> that ODBC is a bit complex.  These are all my perceptions, I could be
ak> wrong.

Well, i've written an abstracion layer on top of ODBC which hides all
the strange things ODBC does with memory mgmt.

Implemented are gnome_db_login, gnome_db_cursor_new,
gnome_db_cursor_exec, gnome_db_cursor_fetchone.


The API looks like:

* db = gnome_db_login(gchar* connection_string, gchar* user, gchar* passwd);

   connection_string is a db specific identifier which identifies the
   database for ODBC it's the DSN. I plan to do something like the
   ODBC mgr in windows where you can setup with DB specific tools
   configuration entries which look sonmething like:

[db1]
connection_string = tcp/ip localhost 1313
dblib=/usr/lib/libscllux.so

[db2]
connection_string = postgreshost:2020
dblib=/usr/lib/libpq.so

......

and the connection_string for gnome_db_login ist `db1' or `db2'

* cursor = gnome_db_cursor_new(db, "cursor1");

  returns a cursor with name "cursor1".

* rc = gnome_db_cursor_execute(cursor, <sql string with parameters>,
                               <parameter list>);

  prepares the cursor and executes the statement. <sql string with
  parameters> is the query where variables are indicated with a `?'.
  <parameter list> is a list of values used to substitute the `?'
  variables in the query.

  rc is either:
   0 for success and query is a select stmt.
   > 0 number of affected rows if query is simething like update or
   insert.
   -1 on error

* dbr = gnome_db_cursor_fetchone(cursor);

  returns one dbr (database row) from the cursor's query. It also
  emits the signal `new-values' if new values have been fetched. You
  can bind to this signal to update am entry_field. dbr is passed as
  a parameter to the signal function.

* rc = gnome_db_cursor_close(cursor, <drop everything>)

  closes the cursor. if <drop everything> is TRUE, all db context and
  associated memory is freed for this cursor

* description = gnome_db_cursor_description(cursor);

  returns a GPtrArray* which holds description entries for the
  resulting rows of the SQL statement associated with the cursor.
  Each entry of this aray is a ptr to a struct:
     name of the column
     type of the coumn
     precision, sclane, length, is_nullable, .... and other
     information. 

All gnome_db_... functions emit 2 singals "db-warning" and "db-error" 
if something goes wrong in any of these functions. the defaul handler
just raise a dialog box with the error msg, but it is also possible to 
intercept the signals, handle the error and stop the default handlers
to run. 

That's the currently implemented interface. If someone can write an
postgresql interface to these functions, i'll do the dynaloading stuff
for these functions (i don't like the postgresql interface. i've
worked to long with the old postgres 4.2 release :-(.

MySQL has an ODBC interface and i think the postgresql ODBC interface
could  be ported from win32 to unix pretty easy.

    
what do you think?


ak> -- 
ak>          To unsubscribe: mail gnome-list-request@gnome.org with 
ak>                        "unsubscribe" as the Subject.

--
Michael Lausch/g.a.m.s. edv dienstleistungen gmbh
See my web page <http://www.gams.net/~mla> or query PGP key server for PGP key.
"Reality is that which, when you stop believing in it, doesn't go away".
                -- Philip K. Dick



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