Re: [gnome-db] New project

[Rodrigo Moya <rodrigo gnome-db org>]

On Fri, 2003-05-09 at 19:02, C.J. Collier wrote:
> On Fri, 2003-05-09 at 04:36, Rodrigo Moya wrote:
> > > How'd you get the docbook documentation in the first place?
> > > 
> > writing it directly in DocBook format, in doc/C/mergeant.sgml.
> 
> Is there a GUI DocBook editor, or are you using vi/emacs?
> 
I don't use any GUI docbook editor, I use emacs, so can't tell you.

> > > I thought that might be a way to go about it.  Does libgda cache the
> > > data in memory?
> > >
> > as long as the data model is not destroyed, the data is in memory. Or
> > are you talking about keeping it in a cache, regardless of whether the
> > data model has been destroyed or not?
> 
> I don't know enough about the data model or libgda to answer this
> question intelligently.
> 
a data model is a recordset, that is, a set of rows as returned from the
database.

> > > It'd be more efficient than making queries to the data
> > > source from each application.  I wouldn't want wait 2ms for each request
> > > I make from my 3d apps, especially if I'm doing rotation and streching
> > > and realtime stuff like that.  Perhaps shared memory is a good way to go
> > > about this?  I don't know much about this stuff...
> > > 
> > hmm, passing all the data model via drag & drop might be quicker, or
> > slower, not sure. You could pass it in XML format, or just pass a
> > reference in the form of a Bonobo moniker, to be activated from the app
> > where the data is dropped. Then, in the dragged app, you can just return
> > the data model when asked for the moniker.
> 
> What does the data model look like?  Is it just a DSN?  I would assume
> all the real data is stored/managed by libgda, and that you can access
> these data through a DSN/table/row URI.  Is this true?
> 
you execute a command and you get a data model, which, as I said, is a
class that represents a set of rows as returned from the database.

> Maybe I should learn Bonobo.  There sure are a lot of things to know :)
> 
yeah

> > > Can you tell me where to start if I want to learn the libgda api and see
> > > some simple, practical examples?
> > > 
> > well, to learn the API, look at the sources themselves, they're the best
> > "documentation". As a simple example, we've got gda-test, in
> > libgda/testing. It's not that simple, since it's an API test program,
> > but might give you a good vision of how the API is used.
> 
> Alrighty.  I'll jump into it.  Can you tell me a good starting point? 
> Otherwise, I think I'll start alpha-numericly ;)
> 
have a look at client.c in testing/. That implements the database access
part of the test program. Then, you've got models.c, which shows how to
use the data models.

> > > Hear hear.  Would building a provider for CSV would be a good start,
> > > then?  It may teach me a bit about data mangling and providing a clean
> > > API.
> > > 
> > yes, it might be a good start. It's planned indeed, so if you want to
> > work on it, go ahead. Only one thing to have in mind is having a
> > libgda-generic provider, as was suggested, that implements all the
> > common stuff, only leaving the file I/O part to the real provider.
> 
> Alrighty.  I'll learn the source and then go about writing a CSV
> provider.  this may take a while.  If someone else who wants the project
> comes along, don't tell them they can't do it just because I've already
> started.  I'll keep you all informed of my progress.
> 
ok

cheers