[Biojava-l] Re: persistance

[Aaron Kitzmiller]

I like the interfaces quite a bit so far, and we really appreciate the decision to do interfaces.  It's much easier to incorporate specific, persistent objects.  Your point about features, as well, is well taken, since features may be substantial in their own right.

We've considered your point about brokers sounding an awful lot like factories.  Because databases are responsible for assigning primary keys, any object that wraps database interaction, must incorporate factory-type methods.  However, we also have update() and insert() methods, as well as query construction methods that can potentially involve other objects (e.g. retrieve sequence objects based on cluster membership).  While it may still be an extended version of a factory, in my mind it seemed to deserve another name.

Aaron Kitzmiller
Manager Systems Development -Cambridge
Bioinformatics Department
35 Cambridge Park Dr.
Cambridge, MA 02140
Phone: (617) 665-6831
Fax: (617) 665-8870
Email: akitzmiller@genetics.com

>>> Matthew Pocock <mrp@sanger.ac.uk> 05/02 7:11 AM >>>
Dear Aaron,

This sounds realy exciting. I have no experience of implementing persistance, but I have played with the Java sql bindings & found them to work fine. How do you find the BioJava interfaces so far? If anything seems silly or is unclear then please tell us.

Aaron Kitzmiller wrote:

> A couple of us at Genetics Institute have been working with biojava objects with the express purpose of using them in persistence-aware applications.  For large companies, object databases don't make much sense, so we've been developing some object/relational mapping strategies that might be generally useful.  Though the code is in early stages right now, it may be usable in a month or two and we can certainly put it out there.

That would be great. Persistance is a realy key point - the ensemble project is layered over a relational database, and we use Oracle a lot here at the Sanger, so an object/relational mapping sounds generaly usefull.

>
>
> The idea is pretty simple and, I believe, inspired by TOPLink and other O/R mapping tools.  Classes that are supposed to be persisted implement the Persistable interface.  The interface is pretty simple and includes things like getPrimaryKey() and save().  It also includes a method called getBroker() that retrieves an object that implements the Broker interface.  The Broker class, which is implemented for a particular type of object, actually handles the SQL necessary to return a set of objects that match query criteria, create the object, and insert or update an object.  It's just a single place to do all of your SQL.  You don't get much out-of-the-box with these interfaces since they have to be constructed for a particular database schema.  However, you get a fairly flexible and consistent way to isolate your data objects from the way in which they are created.
>

The broker object may already be supported to some extent alread (or be easy to hide) by the SequenceFactory interface, and also the fact that features must be added to sequences using the createFeature(template) method - this allows a client (gui or script) to request features to be added to a sequence, and lets the sequence implementation choose the correct implementation class for the job.

>
> If there is enough interest (and we can get it past the censors), we'll submit the code to biojava.  We can probably even submit the code for the particular relational database that we're using.
>

That would be realy cool. All the best.

Matthew
--
Joon: You're out of your tree
Sam:  It wasn't my tree
                                                 (Benny & Joon)