Questions and Answers to Database Interface Concerns
Tuesday, July 22, 2002

Transcribed from an e-mail correspondence between Team Doug and MIKAM Tribe.

> Hi,
> We've been working on the interface for the data store, and we were
> thinking about how exactly things are going to work.
> How were you thinking the backups would work?  Right now, we're 
> that the model will send information to the data store as it changes: 
> example, when the cab changes state you would send the cab 
information to
> the data store, or when a new customer is created.

	That sounds right to me.  We should be able to call your interface
methods in order to add information on a "need" basis.

> Also, what information are you going to need to restore the model in 
> of a crash?  We think storing queues, for example, would not be 
> in addition to being slow.  How do you want that data packaged?  One 
> object, or lots of "get" functions?  Incidentally, we are definitely 
> store customer objects, cab objects, and zone geographic information.

	It doesn't matter how the information is stored.  It's all up to
you guys to decide.  As long as we have access to the most up-to-date
information as possible, we will go along with your interface.  It's 
up to you whether you want to pass that info through one huge object or
lots of "get" functions, but if you use one huge object, won't you 
need lots of "get" functions so we can access the data within the 

> Have you figured out how you're representing zones geographically 
> Please try to make it easy on the database :)

	I have no idea.  Originally, we considered a "mapper" class where
you would feed in the address or GPS location, and it would spit out 
corresponding zone.  However, I don't know what happened to that idea;
whether it got lost in the transition from one architecture to the 
or if a group took responsibility for that.  I'll send out an e-mail to
the team leads.

> We could use some extra information in the Customer class:
>  We would like
> a reference to the cab the customer is in (if any).

	Right now, we have a reference to the customer in the cab class.
If you would also like a reference to the cab from the customer class, 
can try to add that in too.

> Also, we're not sure
> if you have an idea of what the "time of pickup" variable is going to 
> for, but we
> have a suggestion that will make our lives easier: for future 
> this is obviously the time they wish to be picked up, but for "now"
> customers, we would like this to be the time the scheduler promised 
> the cab would pick them up.  For hailed customers, this would be the
> current time.

	Sure, that works and we'll keep that in mind.

> We would also like some indication of the type of transaction: hailed
> cab, reservation, or "now" call (this one needs a better name).

	Sure.  Who would you like to keep that information?  The customer
or the cab?  It makes sense to add it to the customer, but just tell us
what you need and we'll try to accommodate.

> Thanks,
> Team Doug