Alan W Morgan

Sorry, should've checked that first.

Sorry if this has been asked before but had a search and couldn't find it.

How are you guys checking 48 hour rule ?

My first thought was take date (in form yyyy/mm/dd) and create a GregorianCalendar.
Now take current date and do same.
Call getTimeInMillis() on both and compare.
As long as current is before and less than 2 days worth of milliseconds its ok.

But I don't really like this solution.
Plus not sure what time of day is defaulted to if you create a GregorianCalendar with just year, month, day.

Thoughts ?

Now, what is to prevent clientB from using lockCookie1 to work with or unlock record7?

Ok but how does clientB get lockCookie1 ?

BTW, locking the entire database is not necessary. You should only account for locking the record in question.

What about the case Zee mentioned where I have to reuse deleted records when creating new ones if possible.
clientA does a read() and figures that record 2 is deleted.
Meanwhile clientB goes and deletes record 1
ClientA creates a new record over record 2.
This is not a big deal really but to be correct they should have used record 1.

By locking the whole DB I can avoid this.

What am I missing here ?


Thanks,
Alan.

[ June 21, 2005: Message edited by: Alan W Morgan ]
[ June 21, 2005: Message edited by: Alan W Morgan ]

The wording in the background section of the application overview which is the only place it is mentioned is as follows :

"URLyBird is a broker of discount hotel rooms. They sell accomodations for business and pleasure travellers at short notice, helping hotels to fill rooms that would otherwise be left empty. They take bookings only within 48 hours of the start of room occupancy. Curently, URLyBird sells the rooms over the phone using a team of customer service representatives (CSRs). The CSRs interact with an aging custom-written application that has been drawing increasing criticism from the CSRs. In the future, URLyBird wants to move into Internet-based marketing, and hopes to be able to accept bookings direct from customers over the web. "

Hey all,

I read a few places that ppl were enforcing the 48 hour rule on the UI.
That is to say that if the date on the room if not within 48 hours of current date then you can't book it.

I was just looking at my data file and noticed that only 4 of them aren't in the past.
If I enforce this then how will anyone even test it as the chances of the test being within 48 of the date is very remote.

Thoughts ?

Originally posted by Jared Chapman:
Hey Alan,

The first think you should do in the read method is to check the flag. So to do this, you should navigate to (offset * recNo) in your data file. Then, you read the flag. If the record is marked as valid, then return the fields (i.e. name, location...etc) in a String[]. If the record is marked as invalid, then throw a RecordNotFoundException. At this point, the file pointer will be at the beginning of the first field (name). If the record is valid, read the fields of the record, populate your string array, and return it.

As far as deleting a record goes, you simply want to navigate to (offset * recNo), which will put you at the flag, and write OxFF. So according to my specs, you don't use read or update at all to delete a record, but rather use a delete(recNo) method.

Hope this helped.

Hey Jared,

Your explanation is exactly the way I was thinking initially but for some reason I got to thinking that there was a better way.

Lastly 00 and OxFF - whats the best way to deal with these bytes ?...as ints ?

Originally posted by Jared Chapman:
I wouldn't return this with the String[]. If the flag specifies that the record is deleted/invalid, then just throw a RecordNotFoundException.

I was thinking the same way myself but then I looked at method signature
and comment on supplied DB file

// Reads a record from the file. Returns an array where each
// element is a record value.
public String[] read(int recNo) throws RecordNotFoundException;

It doesn't preclude returning invlaid records.
And then the question is how do I delete a record.
If read return the flag in the array then I simply have delete do a read and then update returned string array to change flag and call update passing string array.

If not then I have to go SIZEOFRECORDINBYTES * recno - 1 into byte array and change the relevant byte.

Just seemed cleaner to return the flag but I'm prepared to be talked out of it


Do you do delete similar to way set out above ?

Hey,

My read methods signature is as follows :
public String[] read(int recNo) throws RecordNotFoundException

The first byte of my record is a flag to say deleted or not.
Orinigally I wasn't returning this in the String[] but not I'm thinking that it does make sense.
However when I try to convert it to a String I get a period - '.'
Spec says 00 for valid and OxFF for deleted.
How have the rest of ye dealt with this ?

Thanks,
Alan.

Ok I get you now.

I think my design is slightly different so I'm not sure your way makes sense for me.

By the way is there an advantage to not locking when running in local mode.
I was gonna lock regardless of mode for simplicity ?

Originally posted by Ta Ri Ki Sun:
I have a Record class, which has Columns, and a Room which is a Record. I refer to that column as Room.OWNER when working with the String[], else it's room.setOwner(owner)

Ok when you say "I refer to that column" which class is this in ?

Do you have a book method and if so where is it ?

Originally posted by Ta Ri Ki Sun:


Hi Alan
Create and delete, I've yet to see someone post that they've passed without implementing those methods, they may have, and never posted, or I didn't see it. The interface has to be implemented, and there's a good chance those methods form part of their tests.

Unbook/cancel booking is unheard of, but I made it easier to later implement this by not filtering records displayed to the user based on whether they're booked or not. All records, except deleted ones, are displayed, even if they're in the past. As I said last week I feel this allows a user to do more than make a booking, they can track bookings, confirm a clients booking, print a report when filtering a specific hotel or location, and possibly in the future cancel a booking.

Whatever you do make sure you can justify your decision, and you should be alright

Thanks for the reply.
What you said about automated testing makes sense.
So I'll implement them in the DB but no expose them to the GUI.

Good point on not filtering on booked records.
Your explanation has sold me on it.

Hey,

Doing URLyBird 1.1.3 and have questions on Unbook, Create and Delete.

Create and Delete are method on my DB interface but are not mentioned in GUI requirements.
So to follow the mantra of if its not in don't do it I'm not putting the ability to Delete or Create on my UI.
But do I still have to implement it on the DB side for future purposes ?

UnBook is not mentioned anywhere. This means that once I book a record I can never unbook it. Logically it doesn't make sense.
But again if its not mentioned should I do it ?
And if I don't worry about it do I still have to check if a record is booked before I update it as the only records I will disply in UI will be those available to book surely ?

Any thoughts would be appreciated.

Alan.

Hey guys,

Doing URLyBird 1.1.3 and having some trouble with controller.
My controller has a bookRecord method.
As part of this I update the record with the customer number.
This means that I need to update the last element in the array of Strings that make up the record.
I know this is element 6. In my Data class its referred to as a constant.
I was thinking of simply doing record[Data.OWNER] until I realised that I am dealing with the interface DB and not Data directly.

I could just put constants in controller class but do I really want the controller worrying about this ?

I could also add these constants to my interface but to be honest I want to avoid changing the sacred interface if I can.

Any thoughts ?

Thanks,
Alan.

Thanks again Frans - fat client sounds like it will do me.

One last question -
The requirements say that my data access class must be called Data.java and must implement an interface DB.

My first thought was that Data would be a singleton (I have lockCookie in my
methods) that would control access to my db file.
Then I would need to synchronize certain methods on this class.
Is this ok to do or does it compromise the interface ?

Then I was thinking that Data would contain a Database class that would control access to the db file and Data would simply pass call thru to contained Database.

The second method is closer to the example in the Haibi et al book but is it overkill and is the first solution sufficient.

Thoughts ?

Actually another question just occured to me.

Where should my book method reside ?

Is book Business Logic ?.
If so would it be better off in the Controller/Business logic layer ?.

So book knows it has to lock, check availability, update and unlock all of which are generic Data actions.
However does this mean then that book is on the client side and I end up making mutiple client-server calls as opposed to just one when book was in my DatabaseAdapter ?