Re: CLOS and databases

From: Plamen Stamov (ng_at_stamov.ch)
Date: 03/21/04 

Date: Sun, 21 Mar 2004 03:33:35 +0100

Erann Gat wrote:
> I'm working on a simple object database built on top of a relational
> database. My current design is to have a "storable" mixin class which
> defines two methods, STORE and RETRIEVE, which do the obvious things.
>
> A problem with this simple design is that it places a burden on the user
> to keep track of the relative states of the objects in memory and in the
> DB, and to decide when to STORE and RETRIEVE them. It would be nice to
> make this transparent so that any reference to a slot of a STORABLE object
> would transparently synchronize to the DB. I had envisioned implementing
> this using a :before method on the slot-value and (setf slot-value)
> methods which would check to make sure everything was in sync.
>
> Is there a better way to do it? Is this a job for the MOP?
>
> My goal here is not only to make something functional, but also to
> highlight the power of CLOS with something that will really knock the
> socks off the Java people, so I really want to do this the Right Way.
>
> E.

Hello,

I would not like to discourage you in your enterprise, but I think that
to "really knock the socks off the Java people", you will have to
implement something more difficult than that.

Current O/R mapping products (not only commercial ones) include more or
less the following functionality :
- ACID transactions. In multithreaded environments. Because it usually
matters;
- several mapping schemas for classes, because of the different
performace characteristcs for different access patterns to the
objects/tables, and as second because sometimes people like to access
legacy databases, whose datamodel have the structure of cobol
copy-members and as such is hardly even relational...) and for simple
types (because some legacy applications store a boolean as 1 and 0 in a
field of type VARCHAR(1)...) ;
- support different distribution models (C/S, multitier, in cluster or
not) whith all implications for distibuted transactions and caching;
- some method for making the mapping process easier (GUI, XML etc. -
this is not to say that it is a good solution, but better that nothing :) ;
- support for caching (and sometimes in a cluster);
- support some kind of may be optimizable (in terms of caching ans
translation to SQL) query language;
- the possibility to tune the access methods of the mapping library to
specific contexts (againg because of performance);
- support for all major databases (with the possibility to let you write
your own SQL, for the cases where the tool does this in a too dumb or
incompatible way);
- add some more less important functionality

As a user you have the possibility to choose between several (I know of
at least 15) products with licensing costs between $0 and several
thousends per seat and/or processor (application server not included :)
. With documentation between 0 and up to 800 pages. With support between
0 and somehow usable. With performance between 0 and good in the context
of having a Java O/R layer in your application. With more or less
portability between JVMs, application servers and databases.

Even if every single future is may be trivial, all together are by far
not. Some of the complexity comes from the design of the JVM, Java and
standards like JDBC, EJB and JDO. But the rest comes from questions not
related to Java directly (like distributed transactions and caching).
Not to mention the trade-offs of using O/R mapping in general and in
Java in particular. Actually some of the problems are in Java easier
than in CL, for example you haveto think more about possible mapping
schemas, because you can put in a slot much more things than in Java.

So, to impress a Java people, even if you don't manage to do it the
right way, you would have to at least implement enought functionality
just because in the Java world it is allready there. Not to say, that I
have a lot of positive feelings about the Java world - I just happen to
know somehow the market of O/R mapping tools and some of the
expectations of their users. (Commenting these expectations would be
actually a funny off-topic :)

How easy it is to implement a simple O/R mapping library is allready
demonstrated by UnCommonSQL and the like (I'm placing it before
CommonSQL not because of it's qualities, but being open-source, it
allows Java developers to get some concrete Lisp, if they choose to
study O/R-mapping tools for discovering the strenghts of CL).

Of course if you put enought functionality in your project, that would
serve not only Java developers, but also some CL users :)

...
...

One of the posters mentioned one of the Paepcke's papers. There are also
his papers about PCLOS - an O/R mapping framework. But for real code,
you will need to use current MOP documentation. There is also a recent
paper by Arthur Lee and Joseph Zachary called "Adding Support for
Persistence to CLOS via Its Metaobject Protocol". There is also an old
paper by Theodore Phelps, called "Persistent object storage in
collaborative systems".

Some posters mentioned cl-prevalence. Escaping the context of O/R
mapping tools, and entering the one of the Main Memory Databases
(prevalence is such, and besides of the marketing of the original
prevalence project, it is either the first nor best one in history, but
may be the simplest to implement in Java), I think that the concepts
found in projects like HiBase and Monet (there is even a similar and
really good commercial product calles KDB from K Systems, which seem to
predate Monet, but Monet is better documented) are more intersting in
terms of the "Right Way". But both would require a deep understanding of
your CL implementation and/or support from your vendor.

In the context of pure Lisp OODBs there is (besides PLOB) an old paper
from by and Swanson called "UCL+P - Defining and Implementing Persistent
Common Lisp".

I suppose, that enhancing cl-prevalence, implementing a better MMDB or
replacing the backend of PLOB with something accessible, would also be a
great contribution to both communities :)

With best regards
Plamen 

--
Today is the first day of the rest of your life.

Relevant Pages

  • Re: Why use Java Stored Procedures....
    ... Aside from Microsoft databases, most well-known databases support java ... but that is not a Stored Procedure) I ...
    (comp.databases.oracle.server)
  • Re: Which JVM to use under Windows?
    ... be coded to support 1.4, ... Home users have no reason to stay at an old version of Java. ... They just locked their horns with Microsoft and use ...
    (comp.lang.java.programmer)
  • Re: porting from C++Builder
    ... and I do believe that standard support of PME ... the java was growing and, obviously, microsoft initially tried to ...
    (microsoft.public.dotnet.languages.vc)
  • Re: C to Java Byte Code
    ... >So you don't support longs as that term is understood (in contemporary ... But char on Java is actually 2 bytes, ... >many C programs that share or access memory directly will fail. ... MPC speed compared to native C code speed. ...
    (comp.programming)
  • Re: simple web programming options
    ... And that I have seen from CGI/FCGI, Java ... PHP seems to provide the best API of ready-to-use ... doing CGIs specifically and scripted access to databases. ... I recommend PHP highest for language. ...
    (comp.programming)