Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!usc!nic-nac.CSU.net!koko!news
From: Rames Creel <creel@ms.sjdccd.cc.ca.us>
Subject: Re: Smalltalk Object with SQL datatype mapping
Message-ID: <D0JpuM.6vM@koko.csustan.edu>
Sender: news@koko.csustan.edu (USENET News System)
Organization: CSU Stanislaus
References:  <3c5fta$1n7@scipio.cyberstore.ca>
Date: Fri, 9 Dec 1994 13:37:30 GMT
Lines: 23

> If I have an object which map to a row in a SQL table, what should I
> use to initialize the instant variables to?  Should I initialize all
> the instant variables to nil or should I initized them to NULL string
> ("") for string type or numeric zero (0) for numeric variable?  What is
> the pros and cons in either ways?
> 
> In a SQL database, it would prefer to store nil instead of "", for
> example, if there is really noting in that field.  What is the
> convension in SmallTalk environment?  How can we compromised both
> world?  Any comment?
> 
> Howard Hui
> B.C. Automobile Association        
> Burnaby, B.C., Canada
> Email: howardh@bcaa.bc.ca

We found that it is best to initialize the instance variables with the data type that matches database and try to avoid nil whenever possible.  We use an empty string for string classes, 0 for integer, aTimestamp for dates, etc.

There shouldn't be a problem with initializing the object to nil but we use Smalltalk to do reporting from our database.  If we are doing a simple extract and dumping the contents to a file or doing calculations on a column we would have to constantly check for nil values.  Nils were simply not allowed in our database - everything has default values.  The biggest problem we have with default values is with the Timestamps. We used the vendors base date - '17-Nov-1858' as the default.  The obvious drawback h
ere is that this date cannot really be represented in our database, which, in our case, doesn't present a problem.

Rames Creel
San Joaquin Delta College
