Greetings. We're building a "mission-critical" Lisp application that
requires commercial database support. Currently, we're using ACL 5.0.1 (NT)
and AllegroStore (which employs the ObjectStore engine for those
unfamiliar), but the team is having some significant trouble with
ObjectStore, related to contention and corruption (I'm going to omit the
details and yes, we've tried getting help from Franz), so I want to explore
some alternatives.
NB: Our team is small and swamped (of course), and I'm not the "point of
contact" for database issues. However, I'm trying to offload this particular
burden from others.
I'd like to know if folks have had success using a commercial relational DB
such as Oracle with Common Lisp. I'm sure the issues are obvious, such as;
1) how does one effect the mapping of CLOS objects into and out of the DB?
Roll our own interface code? 2) what about queries? We do complex queries on
object slots, and employ AStore inverse functions. [I'm aware of the ODBC
suite offered by Franz, and I think Xanalys has something similar for
LispWorks, but I don't know details. From the description, ODBC looks like a
mechanism for managing legacy data.]
I'm certain these issues aren't atypical and others have had to deal with
them. Apologies if my questions are naive; my background is system software,
not databases specifically. But, this issue is critical for us. We need the
power and reliability of a commercial DB (transactions, concurrency,
rollback, etc.); troubles such as we're experiencing with AStore are just
unacceptable.
Any assistance, opinion, or "shameless plug" is welcome. Thanks much.
--
Regards,
------------------------------------------
David E. Young
CliniSys, Inc.
········@computer.org
http://lisa.sourceforge.net
"But all the world understands my language."
-- Franz Joseph Haydn (1732-1809)
> Greetings. We're building a "mission-critical" Lisp application that
> requires commercial database support. Currently, we're using ACL 5.0.1
(NT)
> and AllegroStore (which employs the ObjectStore engine for those
> unfamiliar), but the team is having some significant trouble with
> ObjectStore, related to contention and corruption (I'm going to omit the
> details and yes, we've tried getting help from Franz), so I want to
explore
> some alternatives.
>
Are the problems you are having with AllegroStore itself or your getting
used to using it. I mean, are there actual AllegroStore Bugs occuring? I
thought AllegroStore had all the transaction, concurrency, that would be
needed. Contention and corruption problems can be caused by your
application side.
If you are having trouble using it, you will encouter the same problems with
a relational database. It might be better to stick with it and tough it out
until you figure out how to utilize it properly.
If AllegroStore is falling down then you might consider switching.
Wade
"Wade Humeniuk" <········@cadvision.com> wrote in message
·················@news3.cadvision.com...
> Are the problems you are having with AllegroStore itself or your getting
> used to using it...
My understanding is the trouble lies either with AllegroStore or
ObjectStore.
> I mean, are there actual AllegroStore Bugs occuring...
That's the current concensus. One of our engineer's is attempting to build a
small test case that illustrates the trouble. We'll see where that leads...
--
------------------------------------------
David E. Young
CliniSys, Inc.
········@computer.org
http://lisa.sourceforge.net
"But all the world understands my language."
-- Franz Joseph Haydn (1732-1809)
"David E. Young" <········@computer.org> wrote in message
·····························@typhoon.southeast.rr.com...
>
> "Wade Humeniuk" <········@cadvision.com> wrote in message
> ·················@news3.cadvision.com...
>
> > Are the problems you are having with AllegroStore itself or your getting
> > used to using it...
>
> My understanding is the trouble lies either with AllegroStore or
> ObjectStore...
And actually, we're devising a work-around that should insulate us from the
issue; I unintentionally made things sound worse than they are. Apologies
all around...
--
------------------------------------------
David E. Young
CliniSys, Inc.
········@computer.org
http://lisa.sourceforge.net
"But all the world understands my language."
-- Franz Joseph Haydn (1732-1809)
On Fri, 03 Aug 2001 21:40:47 GMT, David E. Young <········@computer.org> wrote:
>
>"David E. Young" <········@computer.org> wrote in message
>·····························@typhoon.southeast.rr.com...
>>
>> "Wade Humeniuk" <········@cadvision.com> wrote in message
>> ·················@news3.cadvision.com...
>>
>> > Are the problems you are having with AllegroStore itself or your getting
>> > used to using it...
I've had terrible success with Allegrostore/Object store. I've been
working for over a month to get my SQL database to import without
address full errors. Additionally, performance is dismal for my
application. I'm working with systems with 2GB of RAM. I've worked
with Franz over the last 4 weeks -- I hope that they'll be able to
figure out why Object Store has such a problem with my database.
So far I like the convienence of persistant objects, but I've wasted
such a huge amount of time with this so far that it is wiping out any
productivity gains.
--
Kevin Rosenberg, M.D.
·····@rosenberg.net
David E. Young wrote:
> Greetings. We're building a "mission-critical" Lisp application that
> requires commercial database support. Currently, we're using ACL 5.0.1
> (NT) and AllegroStore (which employs the ObjectStore engine for those
> unfamiliar), but the team is having some significant trouble with
> ObjectStore, related to contention and corruption (I'm going to omit the
> details and yes, we've tried getting help from Franz), so I want to
> explore some alternatives.
>
> NB: Our team is small and swamped (of course), and I'm not the "point of
> contact" for database issues. However, I'm trying to offload this
> particular burden from others.
>
> I'd like to know if folks have had success using a commercial relational
> DB such as Oracle with Common Lisp. I'm sure the issues are obvious, such
> as; 1) how does one effect the mapping of CLOS objects into and out of the
> DB? Roll our own interface code? 2) what about queries? We do complex
> queries on object slots, and employ AStore inverse functions. [I'm aware
> of the ODBC suite offered by Franz, and I think Xanalys has something
> similar for LispWorks, but I don't know details. From the description,
> ODBC looks like a mechanism for managing legacy data.]
>
> I'm certain these issues aren't atypical and others have had to deal with
> them. Apologies if my questions are naive; my background is system
> software, not databases specifically. But, this issue is critical for us.
> We need the power and reliability of a commercial DB (transactions,
> concurrency, rollback, etc.); troubles such as we're experiencing with
> AStore are just unacceptable.
>
> Any assistance, opinion, or "shameless plug" is welcome. Thanks much.
For ACL there's at least Paul Meurers SQL-ODBC which is very similar to the
functional API of Xanalys CommonSQL. On my homepage you can find older
versions of UncommonSQL and SQL-ODBC combined - it could be possible to get
ODBC.-Database access with a nice object-relational mapping for ACL by
combining these two packages. As I stated I already have done this with
older versions of SQL-ODBC and UncommonSQL using LispWorks as Lispsystem
and it is minimal work.
ciao,
Jochen
--
http://www.dataheaven.de
"Jochen Schmidt" <···@dataheaven.de> wrote in message
·················@rznews2.rrze.uni-erlangen.de...
> For ACL there's at least Paul Meurers SQL-ODBC which is very similar to
the
> functional API of Xanalys CommonSQL...
Thanks very much Jochen. I'll have a look.
--
------------------------------------------
David E. Young
CliniSys, Inc.
········@computer.org
http://lisa.sourceforge.net
"But all the world understands my language."
-- Franz Joseph Haydn (1732-1809)
I'm sympathetic to your problems with AllegroStore/ObjectStore. We're
struggling with them, too. When your engineer comes up with the
small test case that demonstrates the problem, please do post it.
Although it is probably possible to use CommonSQL or one of the
various CL / ODBC bindings, doing your own mapping from CLOS and other
lisp objects into something you can reliably store and retrieve from a
relational database could be problematic, depending on what you are
storing.
One alternative that might be worth considering is PLOB:
http://www.lisp.de/software/plob/
Unfortunately, there are some commercial licensing issues with the
underlying database (postore), so check into the legal suitability
before falling in love with the PLOB interface...
Larry
--
Lawrence Hunter, Ph.D.
Director, Center for Computational Pharmacology
Associate Professor of Pharmacology, PMB & Computer Science
URL: http://compbio.uchsc.edu/Hunter
phone (303) 315-1094 UCHSC, Campus Box C236
fax (303) 315-1098 School of Medicine rm 2817b
cell (303) 324-0355 4200 E. 9th Ave.
email: ············@uchsc.edu Denver, CO 80262
>
> I'd like to know if folks have had success using a commercial relational DB
> such as Oracle with Common Lisp. I'm sure the issues are obvious, such as;
> 1) how does one effect the mapping of CLOS objects into and out of the DB?
> Roll our own interface code? 2) what about queries? We do complex queries on
> object slots, and employ AStore inverse functions. [I'm aware of the ODBC
> suite offered by Franz, and I think Xanalys has something similar for
> LispWorks, but I don't know details. From the description, ODBC looks like a
> mechanism for managing legacy data.]
>
I am currently working on my second major application tying Oracle to
Common Lisp (LisWorks on UNIX). This one primarily uses CLOS objects
tied to an expert system (LISA - SourceForge).
LispWorks has the ability to pull instances from and push instances
back into the database. The class is created using def-view-class
macro which adds functionality to the standard defclass macro to
support building instances from the database. It works very well
except for one major limitation, it only supports float, integer and
string datatypes. In particular it is missing the date datatype. It
also has the functions to update a record from an instance or single
slot and delete the record that is associated with the instance. There
is a programmatic interface that allow you to build SQL queries on the
fly. The UNIX version uses the Oracle OCI library, not ODBC.
·······@motorola.com (Art Nuzzo) writes:
> LispWorks has the ability to pull instances from and push instances
> back into the database. The class is created using def-view-class
> macro which adds functionality to the standard defclass macro to
> support building instances from the database. It works very well
> except for one major limitation, it only supports float, integer and
> string datatypes. In particular it is missing the date datatype. It
> also has the functions to update a record from an instance or single
> slot and delete the record that is associated with the
> instance. There is a programmatic interface that allow you to build
> SQL queries on the fly. The UNIX version uses the Oracle OCI
> library, not ODBC.
UncommonSQL is compatible with the LispWorks SQL package, allows the
definition of new datatypes, SQL operators, readers, writers, and
transformers for putting any new lisp datatype into the relational
database. We have used it to put LocalTime (an incomplete homegrown
version of the package described by Erik Naggum) values into the
database. I'm sure you could modify it to handle other data
representations as well. It also supports Oracle8, tho that driver
has not been ported to LispWorks to my knowledge.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
The outer space which me wears it has sexual intercourse. - opus
>
> > LispWorks has the ability to pull instances from and push instances
> > back into the database. The class is created using def-view-class
> > macro which adds functionality to the standard defclass macro to
> > support building instances from the database. It works very well
> > except for one major limitation, it only supports float, integer and
> > string datatypes. In particular it is missing the date datatype. It
> > also has the functions to update a record from an instance or single
> > slot and delete the record that is associated with the
> > instance. There is a programmatic interface that allow you to build
> > SQL queries on the fly. The UNIX version uses the Oracle OCI
> > library, not ODBC.
>
> UncommonSQL is compatible with the LispWorks SQL package, allows the
> definition of new datatypes, SQL operators, readers, writers, and
> transformers for putting any new lisp datatype into the relational
> database. We have used it to put LocalTime (an incomplete homegrown
> version of the package described by Erik Naggum) values into the
> database. I'm sure you could modify it to handle other data
> representations as well. It also supports Oracle8, tho that driver
> has not been ported to LispWorks to my knowledge.
LispWork's standard SQL interface has the capability of
getting/inserting dates but they did not include that capability in
their def-view-class macro that is used to create instances directly
from the database. I'm writting my own functions to basically do the
same without the limitation. I'll take a look at UncommonSQl to see if
it will help get around the issue in def-view-class. Thanks for the
information.
"David E. Young" <········@computer.org> wrote in message
·····························@typhoon.southeast.rr.com...
> Greetings. We're building a "mission-critical" Lisp application that
> requires commercial database support. Currently, we're using ACL 5.0.1
(NT)
> and AllegroStore...
An update on our progress with AllegroStore. First, let me say that our team
agrees that AllegroStore is a fine product that greatly enhances our
software. It has been brought to my attention that some could have
interpreted my original post as a criticism of both AStore and Franz;
certainly not my intention and not indicative of the facts. In the future I
must be more judicious in my choice of words.
Now, to the update. We are currently still investigating our database issues
and have yet to determine the root cause, be it our software or some other
entity. Franz is assisting and I'm certain we'll reach a resolution quickly.
Regards,
--
------------------------------------------
David E. Young
········@computer.org
http://lisa.sourceforge.net
"But all the world understands my language."
-- Franz Joseph Haydn (1732-1809)