Hi,

All this sounds interesting. Comments interspersed.

On 2001.06.01 08:09:09 -0400 William Surowiec wrote:
> David,
>
> Thank you for the reply.
>
> I am currently using IB 5.6 as the database engine. I am running on Win98
> and chicken to mess with a development environment for
> systems in production. If blobs are in InterClient 2 for IB 6.0 I will
> start up another development environment for that.

I would try recompiling 1.6 with java 1.3. I've never used 1.6, but I
would be really surprised if it had _no_ blob support. Are the functions
not implemented or do you get exceptions? Source code for 1.6 is also at
the firebird site, sourceforge.net.projects.firebird in cvs. 2.0 as
released by borland didn't work with jdk 1.3, why should 1.6?


>
> I am using Java 1.3.1. I have downloaded what I believe to be Java client
> code, posted by Alejandro Alberola Arias, at
> http://groups.yahoo.com/group/IB-Java/files/
> I believe this will eventually talk directly to the Interbase engine on
> port 3050. I have compiled the code but cannot yet connect
> to a local Interbase 5.6 database (maybe it needs IB 6.0).

It does need ib 6/firebird, it only talks dialect 3 I think.

This is the very beginnings of a new driver, but is not yet usable for
anything. Again, look in cvs at firebird for the current state of this
project (client-java).
>
> I have not seen the InterClient Java source files, I will go look for
> them and compile them under jdk 1.3.1 as an interim approach.
>
> Finally, your thoughts on XML. I agree that the use of a blob and the xml
> structure embedded within the blob will prevent me from
> directly searching within that body of data. The application is for a
> cancer researcher. He needs a degree of freedom to express the
> protocol details, as they evolve over time, in the collection of data. We
> are looking to remove the programmer from the loop (me).
> He also needs to document any changes made to any recorded datum over
> time. I am exploring XML as a more flexible yet structured
> description of the "data schema". I've considered, for indexing within
> the xml, another table containing roughly three columns:
>
> 1) the id of the blob row (it has a unique id) as a reference
> 2) the path through the xml document to get to the datum being indexed in
> this row
> 3) the datum
>
> I'm still thinking hard about Column 2 above.

I assume you would be using the xsl query path language (XPATH?? I can't
remember the name). In my experience this is not all that easy to use to
get what you expect, at least for beginners.

>
> I figure some kind of tool, driven by the researcher, would step through
> the XML records extracting the paths he selects and storing
> them in the above table. It would be nice to have Java on the server to
> handle triggers when the blob is updated!

Do you mean having java udfs?
>
> Bill

As I understand it one of the things you have to support is the metadata or
structure of the data changing: perhaps modeled as the xml dtd changing.
This is a very hard problem I think, usually ignored by everyone. In my
experience most people, programmers and scientists includeed, have a very
hard time holding 2 metadata structures in their mind at once and thinking
about the differences. Plus in a research setting you have to have pretty
much a no update or delete database.

One possibility you might consider is something like this:

"metadata tables"

types (
id
name
version)

type-relationships (
id
name
version
from-type
to-type)

"data tables"

data (
id
type-id
data
version)

relationships (
id
type-relationship-id
from-data-id
to-data-id
version)


This definitely makes it harder to get "the contents of one xml document"
but keeps each piece of data in exactly one place. Possibly it would make
querying across versions more plausible also.



david jencks