[elephant-devel] Is there any reason not to develop a Postgresqlb ack-end?

Robert L. Read read at robertlread.net
Thu Sep 15 14:35:38 UTC 2005


IMHO:

I am using Elephant happily now, and want to go live with a system that
uses it, but can't abide
by the Berkeley-DB licensing restrictions.

After 48 hours considering the problem, you are correct---it will
require some major rewriting, at least
to be elegant.  I can remain code-back-compatible, but the class
structure of the controller has
to be significantly extended.

As to CL-SQL, it is a fabulous system; in fact, Elephant can sit on-top
of CL-SQL and thus,
more or less easily use the 5 or 6 backend databases that CL-SQL
supports easily.  My goal
would be to seamless support that, as well as the Berekely-db, so that
one can simultaneously
use different systems.  One of the beauties of such as system is that
one can migrate from
one DB implementation to another almost trivially if one can
simultaneously read LISP objects
out of Sleepycat and put them into Postgres, for example.

CL-SQL also, as you point out, provides a relatively easy way of getting
CLOS objects into
a database, by allowing one to easily specify a mapping onto SQL-data
types for each slot.
This is similar to Hibernate in the Java world.  Although this is
valuable for some applications,
I think the Elephant persistent object approach is even more valuable.
For the work I've been doing
for the last 8 months, it is wonderful to be able to change a class and
have it just work with
Elephant, and not even have that small additional step that CL-SQL
requires of mapping things
into SQL data types.  This savings in labor is relatively small, but
worth fighting for!

Although I might chicken-out, my current plan is to continue rewriting
Elephant so that it 
can use both Berkeley-DB and CL-SQL.  I will then be morally compelled
to release this
under the GPL, since Elephant is under the GPL, even if not legally
compelled to do so 
since I am not redistributing the code to anyone.  I would rather get
some kind of opinion or 
approval from the existing Elephant owners, if they agree it is
worthwhile, than to release it 
as a fork.  It will require some approval because it will be a pretty
major rewrite; not just
a patch or extension.

As to owning Elephant, it seems sensible that I could do it if I manage
to complete this non-trivial
programming project satisfactorily.  However, I am not yet a masterful
LISP programmer, and 
moreover have never owned a public software project and have no idea
what that entails.  If 
one of y'all can describe the responsibility to me accurately, then I
might consider it.

Finally, do we have any idea how many people are using Elephant?  If I
do this work, will
I be the only person using it?  If it's not going to help very many
people, I could just do 
the extra work to construct the CL-SQL mappings and save myself a lot of
time.


On Thu, 2005-09-15 at 18:49 +0900, Ben wrote:

> we (the elephant owners) have been silent for far too long, sorry.  to
> make a long story short -- neither of us have time to own elephant
> anymore.  we've been debating on the side about how to deal with the
> lack of time, and have procrastinated more and more....
> 
> so we're looking for a new owner for elephant.  we'll be happy to
> answer what questions we can, but i don't forsee having the time to
> deal with this for at least a year (or whenever my dissertation is
> done.)  i'm really sorry to leave you folks hanging.
> 
> the good news is i think it shouldn't be too hard to deal with the
> code base, which as you can see is not too big.  the code is also
> fairly modular: there's some CLOS magic to make persistent objects, a
> lisp datatype to byte stream serializer, and then the berkeley db back
> end.  plus a bit more here and there.
> 
> to answer the immediate question, i don't think there's any reason why
> one couldn't write a postgresql back end, but it might require some
> thinking about redesign.  elephant assumes that the underlying
> database is byte-oriented.  i assume this is possible with postgresql
> but it doesn't really make much sense to use an SQL database without
> using the SQL types.  that's just my opinion though.  if one wanted to
> use SQL data types then maybe one should try out CL-SQL or somesuch? 
> i dunno.  i think there are other possibilities for a back end. 
> someone on the list a while back was talking about writing a lisp back
> end.  that would be interesting.  i think sqllite might also be a
> possibility.
> 
> there's a few patches hanging around in my mail folders (probably on
> the list archive) which should be applied.  the CVS elephant is close
> to a release, it just needs some tagging and regression testing.
> 
> sorry i'm writing from korea and i'm rather jetlagged.  but i'll be
> back in the states soon.
> 
> any takers? 
> 
> Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20050915/e3435a14/attachment.html>


More information about the elephant-devel mailing list