Path: news.cs.au.dk!news.net.uni-c.dk!sunsite.auc.dk!newsfeed1.uni2.dk!newsfeed1.swip.net!swipnet!news.tele2.nl!newsgate.cistron.nl!het.net!newsfeed.wirehub.nl!skynet.be!poster!not-for-mail From: Jean-Louis Leroy Newsgroups: comp.lang.beta Subject: Re: Beta/Mjolner versus Relational Databases Date: Fri, 08 Jan 1999 22:42:29 +0100 Organization: Starfleet Lines: 93 Message-ID: References: <19990108075745.10956.qmail@noatun.mjolner.dk> <36961139.A4DC9791@cs.au.dk> Reply-To: jll@skynet.be NNTP-Posting-Host: dialup471.brussels2.skynet.be Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: news1.skynet.be 915831163 2028 195.238.24.215 (8 Jan 1999 21:32:43 GMT) X-Complaints-To: abuse@skynet.be NNTP-Posting-Date: 8 Jan 1999 21:32:43 GMT X-Newsreader: Virtual Access by Ashmount Research Ltd, http://www.ashmount.com Xref: news.cs.au.dk comp.lang.beta:11779 In article <36961139.A4DC9791@cs.au.dk>, Michael Thomsen wrote: > Which features would you expect from such a framework/layer by the way?? 1) Preservation of identity (mandatory) An object in persistent storage should have zero or one counterpart in transient storage. If I open an object cursor on all the Persons named Simpson, and another cursor on all the Persons whose first name is Homer, I may read Homer Simpson via both cursors; I want only one copy present in the process' memory. This can lead to problems in garbage-collected systems, see note below. 2) Polymorphism (mandatory) If I open an object cursor on all the Fruits, I expect the Apples, the Bananas and the Kiwis to show up. 3) Mapping of relations (important) A one-to-one relationship should be mapped to a persistent pointer; a one-to-many or a many-to-many should be mapped to a persistent collection of persistent pointers. 4) Support for cycles (good to have) Then of course if you have relations, you run the risk of creating cycles. A good persistence layer should take care of establishing the cycles for you, because its purpose is to hide the underlying storage model. 5) Efficiency (important) Queries should 'cost' a fixed number of SELECTs; retrieving all the Persons should *not* cost one select per retrieved object, even in the presence of polymorphism. Iterating over collections inside collections inside collections should not lead to an orgy of SELECTs. In general, the computed SQL should look like what a skilled SQL programmer may have written. 6) Load on demand (important) If I load a Person, I don't want to bring in his wife, children, nephews, janitor, tax controller, etc until I actually need them. 7) Good support for language constructs (important) Persistence layers are low-level facilities that should not influence design nor implementation. A C++ persistence mechanism shouldn't forbid the usage of templates or multiple inheritance. 8) Extensive support for RDBMSes' query expressiveness (important) It should be possible to code queries like 'all the persons who have at least one child aged between 5 and 7'. 9) Notational convenience (unimportant but comfortable) Those queries should be expressible in a crisp syntax: # a Perl example my ($parent, $child) = $storage->objects(qw( Person Person )); $storage->select($parent{children}->includes($child) & $child->{age} >= 5 & $child->{age} <= 7 ); 10) No mandatory reliance on extra-linguistic tools (important) It should be possible to exploit the persistence mechanism while staying within the language itself; if this condition is satisfied, providing extra-linguistic tools like schema extractors won't harm. Poet uses a preprocessor to extend C++ with extra keywords. What if you have two tools, each requiring its own preprocessor, each refusing to understand the other's extra keywords? ObjectStore for Java uses a bytecode postprocessor. Before upgrading your language implementation, you must make sure that the postprocessor will understand the new bytecodes. 11) Extensibility (very important) You should be able to teach the persistence layer how to handle your own types. At this point in my evalutation of Beta, I have the impression that (9) is unfeasible, because Beta doesn't seem to support user-defined operators. (1) Is a more important concern. In order to ensure identity preservation, the storage object (representing the RDBMS) must keep track of which objects are already loaded. Thus it must hold references to these objects. Unless the language supports weak references, these objects will never be reclaimed. Well, there are solutions, but they are either inefficient (roll your own memory-management scheme) or unfriendly (have the programmer manually purge or refresh objects). Does Beta have weak references? Then Beta seems to lack the notion of destructor à la C++ or finalizer à la Java. They're needed for cleaning up the loaded object table. How have you addressed these issues? Jean-Louis Leroy http://ourworld.compuserve.com/homepages/jl_leroy/