Re: S.O.D.A. database Query API - call for comments

From: AV <avek_nospam__at_videotron.ca>
Date: Sun, 29 Apr 2001 19:36:48 -0400
Message-ID: <XG1H6.2008$ZH.261036_at_weber.videotron.net>


Hello Carl,

"Carl Rosenberger" <carl_at_db4o.com> wrote in message news:9cgv1d$lf3$07$1_at_news.t-online.com...
> 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.
 ..yes, sure...
> 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.

...yes, all my comments are from Java prospective...

> 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.
>
...unless there is really some serious pressure from other languages, may be chosing Iterator would be OK - there is always easy way to create Adapter to Enumerator. I belive EJB is moving Collection around.

> > -- 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.
>
...ok, so SODA is not database access layer but database [language] itself...
Thus, class Individual is not java dataobject, but analog of "create table ....". Mapping is still needed, but can be simpler (because of promised inheretance) than OR one...
>
> - Typical getter/setters might be obsolete in the near future. Have a look
> at properties in C#.
>
...may be with arrival of C#_at_&++=- databases will be obsolete also... :-)

AlexV Received on Mon Apr 30 2001 - 01:36:48 CEST

Original text of this message