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 thinking > that the model will send information to the data store as it changes: for > 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 case > of a crash? We think storing queues, for example, would not be necessary > in addition to being slow. How do you want that data packaged? One huge > object, or lots of "get" functions? Incidentally, we are definitely going > 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 all 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 still need lots of "get" functions so we can access the data within the object? > Have you figured out how you're representing zones geographically yet? > 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 the corresponding zone. However, I don't know what happened to that idea; whether it got lost in the transition from one architecture to the other, 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, we 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 be > for, but we > have a suggestion that will make our lives easier: for future customers, > 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 that > 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 > >