[Biojava-l] persistence for org.biojava.bio.seq and org.biojava.bio.symbol

[Gerald Loeffler]

Hi!

Are there any opinions/experiences/implementations out there regarding
the persistence of objects from the org.biojava.bio.seq and
org.biojava.bio.symbol packages, most notably Sequence?!

E.g. imagine that a tool allows users to (interactively) create Sequence
objects, complete with SymbolList, Features and Annotations.
Additionally, Alignment objects might be constructed that make use of
these Sequence objects. How are we to make the so created (highly
complex) graph of objects persistent, such that all objects will be
available in later invocations of the tool?

Two extreme mechanisms of persistence seem logical:
  1) persisting a Sequence object (and the object graph originating at
this object) to a well-known flat-file format (EMBL, GenBank, MSF, ...)
(with the advantages of platform-neutrality, familiarity, easy exchange,
and a host of existing tools that could potentially use it, etc.). 
  2) persisting the object graph more or less directly to an
object-oriented database (with the advantages of speed of access,
transaction-safety, networked access, access through (OQL or SQL)
queries, automated indexing, etc., etc.). The main disadvantage is
probably that the persistent store in this way depends on implementation
details of the persistent classes (ODBMSs store object fields and if you
change the fields of your persistent classes you risk not being able to
read objects from the ODMBS - even if the external contract of your
class (it's protected and public methods) remains entirely intact!).

(Recently i've made intimate contact with object-oriented databases from
Java (see ODMG 3.0 under http://www.odmg.org/) and grew quite fond of
them - especially in contrast to relational databases when the
object-model to persists is very complicated (as the one implemented in
org.biojava.bio.seq and org.biojava.bio.symbol surely is)!)

Any opinions on this?

	cheers,
	gerald

P.S.: I'm off now to a 6-day holiday, so I'll only be able to respond to
your mails after my return...
-- 
   Gerald.Loeffler@vienna.at _________________ Software Architect
   http://www.imp.univie.ac.at ____ http://www.daemonstration.com
   OOA&D, Java, J2EE, JSP, Servlets, JavaBeans, ODBMS, RDBMS, XML