I wrote something yesterday about the db.db file, but I think I wasn't clear enough what I meant so I will try again.
My problem with the db.db file is that I consider it to be a description file more than a database. It contains
1)a description of all flights that exists
2)the number of seats available defines number of seats in the airplane; i.e. small or big plane
3)you shouldn't modify it
Every time you run your tests it should always be the same at the start, so it will give you the same result; i.e. if you're using Junit or equivalent. If this file is "read-only" you should never write to it. I that case most of the methods in the Data class aren't needed.
So what happen when you book a flight? You should reduce number of seats available for that particular flight. If you can't modify the db.db file I see only two options to do this:
1)either do in memory
2)create a new file for the bookings
But I haven't seen any requirements that you're bookings should be stored in a persistence layer. We all agree?
What troubles me is that I have the feeling that Sun wants me to store records in the db.db file without modifying it; i.e. "At present, a basic data storage and retrieval system (the "database") has been implemented and shown to work by the undergraduate". How is that possible?
For me the db.db file is just read-only for the users of the application. I could be write allowed for a system administrator if a flight I added/modified/deleted by a company.
For me it doesn't make sense to write your bookings into the db.db file, except if you just want to modify the seats available field. But in that case, it will be modified=not allowed.
So my question is, how do you, fellow javarachers, see the persistence layer and the db.db file? Who will add records into it, modify it?
Hope for many answers
Thank your for your quick reply. But as I said, "For me it doesn't make sense to write your bookings into the db.db file, except if you just want to modify the seats available field".
Do you add records in db.db or do you just update it?
Also, why do say that I SHOULD write to this file? I can't see any requirements for this.
The way I see it, when you book x seats on a flight the number of available seats of that flight is diminished with x in db.db. Literally it is never stated explicitly that you SHOULD write into the db.db, but imho it certainly is the most easy and only convenient way to do it. Maybe you think more complex than you need to for this assignment.
Henk van Jaarsveld
You're perfectly right that I thought this assignment was something that actually could work in a production situation, but it's not.
Anyway, I do agree with you that the approach of just modifying the field Seats available is OK. What I don't like about is that the tester just can run the test once with the same file, after it is "corrupted". One solution of this is to make a copy of it every time you start and use this temp file of db.db instead of the real one.
Thanks for your help!
If you do not change the db.db file, how do you handle two clients booking for the same flight. Client A books all the remaining seats, then Client B tries to book a seat. If client A does not change the db.db file, then it will allow client B to book a seat, even though there are none left.
Like Heng said, keep a copy of the original db.db file, you will need it when you submit the assignment.
As far as adding or deleting records, that is not in the specs, and not needed. I think those methods are there from the old days when the assignment came with a text file with data, and you had to write a conversion program to import the data into the db.db file, and you needed to use the addRecord method of the Data class.
Otherwise, I would worry about them.
Thank you for answering yesterday! About your remark about concurrency the answer is: in memory. You don't need to update the db.db to solve this assignment. At startup you'll read all the records in db.db and then put the DataInfo objects in a Vector. You do lock and unlock, but the modify method with not change the database but the DataInfo object concerned.
I think it will be faster and more simple as well, but I'll stick to the good old db.db anyway.
"Enrico - according to the specs (reading between the lines) you should update the db.db."
If think that Sun have done a wonderful job.;( Now we have to read between the lines in a spec!
No offence, Gregory, but I do not read this. Ok, I do agree that's what they want us to do, but what a specification.
In real life, not a single line of code would have been written with such a specification! It's just one thing to do with such a specification - back to marketing! Rewrite!
The user must be able to book one or more seats on a chosen flight. If the flight cannot provide those seats, the user must be informed. It is not necessary to provide for live updates on multiple clients when new bookings are made at other clients
If the flight cannot provide those seats. As in you tried to book more seats than were available. If Client A books all the seats, should Client B be able to book seats on the same flight too, when none are now available.
The second part leaves some confusion, but Literally it states that if Client A books those Seats, Client B does not have to see the decrease in seats automatically. He could get them by re-searching and refreshing his data via a search.
As a customer I don't want to book a seat only to find out when I arrive at the airport there really wasn't any seats remaining.
I understand what you're saying and I agree. But I don't understand why you're saying it. You can choose to update the db.db file or do it memory, the application will have the same behaviour.
Also, this application will never be used because it's totally useless in the real world. So I shouldn't bother with that. It would have been nicer if Sun would have come up with a specification that could be realistic, maybe harder but much more fun. Because, who wants to spend time of doing something that never will be in production?