incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Weatherup <graham...@hotmail.com>
Subject RE: Database base odb support
Date Fri, 13 Jul 2012 17:57:07 GMT
Hi Rob,

Thank you for your help.

Our software (PAMGuard.org) is used to process acoustic data and output results to database.
Tables hold information such as GPS data, audio file data then outputs from the processing
of the files. We do allow storage to serialised binary files for data which is just being
used PAMGuard but people like data output to database(currently access or mysql) so they can
work on it for their own analysis of the output and so they can share the data easily.

There are several reasons we would like to include .odb support.

There are good free GUI editors that people can work with. OOo and Libre (I have not found
such good editors for SQLite and most of our users are not SQL savvy but want to be able to
run queries etc)
Being able to use pure java hsql driver should allow for 64 bit support for extra RAM usage.
Giving the option of in-RAM databases may increase speed which should be possible with hsql
Single files are easy for our users to send to each other.

Below is the response I got from LibreOffice mailing list suggesting ODFToolkit. For the fastest
implementation all I need to work out is the zipping issue of mimetype etc and if any other
file get edited. However if I had the expertise I would much prefer to write the abstraction
layer you talk of but I really don't have enough knowledge or understanding of even writing
on top of ODFDOM to do something like that.

>From what I hear OOo works by working on the database and polling changes to the Zip(odb)
file so data is not lost during a crash. Extracting it is more clumsy and risky but it get
a working solution. The ODF toolkit must be able to at least deal with the zipping issue I
mean in that it must be the same in odt/ods files.

Graham

>>>>>>>>>>>>>>>>>>>>>>>>>>>
hi Graham,

On 09/07/12 16:53, Graham Weatherup wrote:

> The above link also directs to a description of how to unzip it in
> java** so I figured I should be able to zip the files up and open it 
> again with Open Office. When I zip the files with java.util.zip using 
> the method here***  the file called ‘mimetype’ comes out “compressed”
> but actually bigger and even setting compression off in the its still 
> bigger but not as much 41bytes vs 43bytes (I don’t remember the 
> numbers
> exactly) but not the 39bytes that is required. Also I read on a linux 
> forum that I cannot find that mimetype has to be ‘at the beginning’ of 
> the file. 
>
> Also I wonder if there are any files that should be updated if tables 
> get added etc. any other files in the ODB file?
> 
>* http://programmaremobile.blogspot.co.uk/2009/01/java-and-openoffice-base-db-through.html
>**  http://digiassn.blogspot.co.uk/2006/07/java-creating-jdbc-connection-to.html
>*** http://www.crazysquirrel.com/computing/java/basics/java-directory-zipping.jspx
>**** http://www.oooforum.org/forum/viewtopic.phtml?p=257220&highlight=#257220

there are very specific requirements on the "mimetype" file that are likely difficult for
generic zip libraries etc.; note that there is an ODFDOM project that is a Java library that
supports the ODF package specification directly so it makes this kind of thing much easier
(it will also maintain the manifest automatically for you); it is now part of the Apache ODF
Toolkit project.

http://incubator.apache.org/odftoolkit/

if you use a generic zip library then you should really read the ODF 1.2 part 3 specification
to understand the special requirements.

i'm not familiar with the database part of ODF, but i could imagine it contains meta-data
like column descriptions and such; for details refer to ODF 1.2 part 1 specification.

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

>>>>>>>>>>>>>>>>>>>>>>>>>>>





-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: 13 July 2012 13:38
To: odf-dev@incubator.apache.org
Subject: Re: Database base odb support

On Fri, Jul 13, 2012 at 6:17 AM, Graham Weatherup <grahamy2k@hotmail.com> wrote:
> I was directed to this toolkit by Michael Stahl from the LibreOffice 
> dev list and would really like to use it for our java application 
> PAMGuard. I assume it will maintain support for LibreOffice and 
> OpenOffice as the files are the same?
>

I theory, yes, since ODF is a standard and the ODF Toolkit is based on the standardized schemas.
 At the lowest level the Toolkit code is machine generated from the schemas themselves, so
it is a very faithful implementation of the standard.


> I don't see any example/demos for databases or anything like 
> DatabaseDocument in the Simple API.
>
> Having looked at the source code I see the package 
> org.odftoolkit.odfdom.dom.element.db has a lot of database related classes.
>
> Is this something that is planned for development, side-lined or 
> actually working? If it is working are there any demos/examples that I 
> can use or can someone briefly explain how to use it?
>

I'd be interested in what kind of scenarios you would want to support with database documents.

As you've probably seen, the API is in layers.  At the lowest level is the code generation
and package support.  Then ODFDOM, which maps
1-to-1 to ODF schema elements.  In theory you can do anything you want at this level, though
you do need to know ODF well.  And at the top level, in terms of abstraction, is the Simple
API.  This is a higher level wrapper of document manipulation functionality.

So if your goal is simply to solve an immediate problem, then writing on top of ODFDOM is
the fastest route.  One useful application pattern is to start with an ODF document that was
manually created in OpenOffice, and then write ODFDOM code to modify that document.  This
way generally requires a lot less coding than creating a document from scratch in code.

On the other hand, if your goal is to create an SDK to enable others to create applications
more easily, then writing an abstraction layer in the Simple API  might work better.

Regards,

-Rob
>
>
> Thank You
>
> Graham Weatherup
>


Mime
View raw message