Hello reader, My specification says " You may not modify db.db file, but you may move it". From this I probably think that I cannot add delete and update records on db.db file. So, I was wondering what other operations I can implement in local mode. Except from flexible search because that is obvious. Please do correct me if I am wrong on my idea of creating another binary file which would store objects in data structure instance through Object serialization. And thus I can implement all the add delete and update operations on local mode and with this specification's requirement would also be retained. Or else suggest what else other operations I can perform in local mode ?. Secondly, does it make any sense to use lock / unlock in local mode since there is only single user. All this issue corresponds to LOCAL MODE and not to Remote mode. Looking for your opinions.
Gurpreet. You are absolutely correct, you won't need to have local mode do lock and unlock. As far as the other methods, you should provide them in your DataAccess interface, and implemented in your local version of this class, but the actual GUI doesn't need to add, delete records to the db.db. The reason why those methods are in the Data class was for a previous version of the assignment. So while you will have your DataAccess class also implement those methods with calls back to the Data class, the Client will never actually use those methods. Good Luck Mark
Hi reader, I got your opinion. So, you say only create call backs to Data class ie only prototypes in source code. It would be only demonstration to grader , it is OK . I wanted to ask you another thing that my specification says "In either case, the program must allow the user to specify the location of database". I must tell you that here either means local / remote. With this requirement how shall my program do ?. On command line I cannot force the user to write the location of database. The other thing left is GUI but how ?. Secondly, I would be using many files in both Local and remote modes shall you suggest to create another package to deploy all the common files such that both Local and Remote can use ?. DB.DB file is also one of them. Waiting for your opinion
On command line I cannot force the user to write the location of database. The other thing left is GUI but how ?. Secondly, I would be using many files in both Local and remote modes shall you suggest to create another package to deploy all the common files such that both Local and Remote can use ?. DB.DB file is also one of them.
1. Putting location of the db is an acceptable command line in the specs. You could also have a GUI window that allows them to select or type in the location of the db.db file. Personally I just had the db.db file in the root directory where the executable jars are, and hard-coded the path. You need to use System.getProperty("user.dir") to get the root directory, then append "//db.db" All three ways above work. 2. No you can still keep the classes in their corresponding packages, and just include them in your import statments when the class needs them. I had my LocalDataAccess and RemoteDataAccess classes in the db package.
Hi MArk As u said your LocalDataAccess and RemoteDataAccess classes were in db package ? Any specific reason for that ? The localdataaccess can be in client package and remotedataaccess can ne server package as well ? What abt location of DataAccessFactory that has two methods and returns a remote or local data access ?? Where did u put this ? Amit
Joined: Jun 09, 2002
Hi reader, I used JFileChooser class for my Local mode in order to specify the location of db.db file. Is this thing acceptable ?. Secondly, I was thinking to hard code the location of db.db file when client will use Remote mode. Because I am of opinion that guys who will test my code will seperate my client code from server code ie client will run on other machine and server code on another. In this case if I hard code the server in order to specify the location of db.db file and on other hand I allow the user to specify the location of db.db file by using JFileChooser, will this be acceptable ?. waiting for your opinions
Hi Amit. I had them in the db package because they were db related. LocalDataAccess could be in the client package, but I thought that if I changed my Data overall, that I would only need to change one package, and not have to go into the client package and make any changes. However, you also need to understand that I lost 4 points on the server, and one of the reasons why was becuase I had the server and the db classes all in the db package, instead of breaking it into db and server packages. I did this early in my assignment before I started to really understand things better, and had never went back to fix it correctly. Mark
Gurpreet, I think it is a great idea to use the JFileChooser. and yes the Server can be hard coded. If you found it really easy to use the JFileChooser on the client, why not also use it on the server, that is of course if you use a GUI on the server, if not, then hard coding is the way I would go. Good Job Mark