From: "Carl Rosenberger" Newsgroups: comp.databases,comp.databases.theory,comp.lang.java.databases,comp.lang.java.programmer Subject: Re: S.O.D.A. database Query API - call for comments Date: Sun, 29 Apr 2001 13:47:16 +0200 Organization: db4o.com Lines: 93 Message-ID: <9cgv1d$lf3$07$1@news.t-online.com> References: <9c4urh$2th$04$1@news.t-online.com> <3AEA1B84.3525@ix.netcom.com> <9cefv8$rb6$00$1@news.t-online.com> <18DG6.12373$5X5.866258@weber.videotron.net> Reply-To: "Carl Rosenberger" Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: news.t-online.com 988544878 07 21987 hpIrSjHVS4-16L 010429 11:47:58 X-Complaints-To: abuse@t-online.com X-Sender: 08936100717-0001@t-dialin.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 AV wrote: > IMHO, from practical point of view, SODA would gain having > -- query returns Collection or array. Why new ObjectSet interface? Hi Alex, The reason against the usage of arrays: You would want to have the ability to instantiate objects on demand. A result of a call to size() might tell you that it would not be a good idea to load 50 million objects over your modem connection. ObjectSet rather is an Iterator or Enumeration than a Collection. Why a new interface? Which standard is supported in a wide range of languages? S.O.D.A. is not intended to be only for Java. Just considering Java, what would you use? JDK 1.1.8 java.util.Enumeration ? hasMoreElements() nextElement() JDK 1.2 java.util.Iterator ? hasNext() next() JDK 1.1.x is far from being dead since it looks like it will be widely used on the Symbian EPOC platform. > -- work with public setter/gutter rather than public attributes > (we are in OO train, aren't we?) You should consider two levels here: A database stores objects with attributes, not with methods. Queries are run against the database. Getters/Setters are used to descibe business logic. You typically do not want to trigger getter business logic upon a call to a database query. Two further points: - Working with setter/getter methods would imply that you would need the code of the application on the server side. The backend for the current approach can work with abstract objects. - Typical getter/setters might be obsolete in the near future. Have a look at properties in C#. > -- examples how to manipulate attributes inherited from subclasses. > -- example of precompiled preparedStatement Thank you for these two hints to continue working on examples. > Question of sql portability has several sides. > -- knowledge of sql and pl/sql is 95-105 % portable 105% ? Are you talking about the portability of code or the portability of coders knowledge? Both are of course portable to some degree. > -- in many (in most?) cases database(s) are fixed This is of course true but evolution always needs to continue. Just consider the effort the mobile telephone industry is currently undertaking to set up packet based communication systems. > -- for programmer of universal db-access layer > several non-standard features are something to deal with... I don't quite understand the point here. > Have a nice week-end! Have a nice Sunday. Thank you very much for your comments. Kind regards, Carl --- Carl Rosenberger db4o - database for objects - http://www.db4o.com