Re: lost in the devel--1.3 branch

> Ok, no problem, I won't dwell too long on the tests then. Even though 

Once you know which test is up to date, it is still a useful knowledge
source :-)

> give it a red hot go. I expect to blunder blindly for a while and to ask 
> some pretty dumb questions, so please bear with me.

You're welcome !

> It seems that:
> 
> 1. The key entities in the core-api are these database objects. All 
> bibliographic citations exist as records in a database.

Right. 

> 2. The fields in a given database are determined by the schema with 
> which it was created (via the dbcreate( ) method).

Yep.

> 3. The schema is typically read from an xml document.

Exact

> 4. Databases may be saved on disk in a number of formats (I used "file", 
> which produced xml, but garlic uses "bsddb").

This is related to the way the database is made persistent. Pyblio has
an XML format for exchanging information. But locally, your database is
made persistent in possibly different ways : in an SQL db, in a file, in
a berkeley DB,... So far there are two which work:

  - file: the storage is simply done in the same format as the exchange
    format (ie an XML file)

  - bsddb : the storage in done in a berkeley db

> 5. The core-api also defines an abstract Record class which provide an 
> abstraction to simplify the manipulation of individual records, 
> irrespective of the corresponding database schema or the format of the 
> underlying database.

Right, the record is what one usually manipulates.

> Am I on the right track here? I havn't really looked into things much 
> further yet, but presumably an application could contain more than one 
> database simultaneously and individual records could be moved from one 
> to another, whole databases could be merged etc. Is is up to individual 
> applications to provide the database schema(s) and the concrete Record 
> classes? 

Records are generic, so you should not need to derive them. The schema
is however your problem :-)

> Getting back to my simple example script above, is there a way to have 
> the bibtex importer simply skip fields in the bibtex entries for which 
> there is no corresponding entry in the core-api database schema? For 
> example, if I wanted to compile some statistics based on a collection of 
> bibtex citations, I might only be interested in say the first author, 
> the title and the year of publication of each citation. I could define a 
> schema containing only those fields and the bibtex importer would 
> (should?) silently discard everything else, like journal names, volume 
> and page numbers etc.

The philosophy is the following : records, attributes, stores, are
generic. What you need to build to provide a complete application is a
schema, and if this schema is related to one of the file formats (like
bibtex), a specialized class that makes the import / export match your
schema. The filters should be only here to minimize the amount of work
needed. So in your case, I think that I should move the exception
handling in the bibtex parser, so that when a field is not known, a
separate method is invoked. The default would raise an error, and you
could override it with a method that simply discard these fields.

> Along a similar line, what happens when the schema defines an attribute 
> for which there is no bibtex analog? For example, if I wanted to sort my 
> citations into categories, I would be tempted to add a category 
> attribute to the schema something like that used by garlic.  Any 
> citations I import from a bibtex database obviously don't include a 
> category field, so I would like them to be placed into a default 
> "unsorted" category. Maybe the way to do this is with a <default> tag in 
> the database schema?

This would also be naturally handled by your specific bibtex importer
subclass. 

Frédéric



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8