OOFS -- Transactional or Transparent (was Re: Testing the waters.)
Fri, 9 May 1997 11:37:56 -0700
This is an issue that I think bears its own thread.
The transparent support described by Adam Alpern is very intriguing, but I
wonder how practical it would be for real-world applications (and I say this
without ever actually used such a system, so my wonderment is only natural). In
my experience, performance and application issues would seem to argue against
having the system decide when and where to store objects for me on its own --
sometimes I don't want things saved, and I'm always seeming to need control of
database interactions at the transaction level.
FWIW, in AgentBase, we simply have a native object type -- ObjectRepository.
Once you have one, then you can store anything in it by key. We also support
(new ObjectRepository: pathString)
(setq myOR[someKey] someObject)
This style is nice in that it makes all sorts of DB-oriented apps very easy to
write. Also, it lends itself to C/S and distributed operation, as the
pathString could be a URL to another server.
Anyway, how would a transparent OOFS work in the context of such applications?
How would the application programmer control database transactions?
The views expressed are mine alone,
unless you agree with me.