URLyBird interface interpretation

[Bj�rn Tikkanen]

Hi

I'm new to this forum and just starting my certification. Lots of things to figure out of course. One thing, how hard should one follow the textual description of the DBAccess interface methods? For example, findByCriteria that states that it should return whatever matches the criterias. If interpretated tough, this means that also deleted records are returned (the flag is not one of the schema described fields). Or, is it ok to add these variables in the method? I was planning to use another class as a kind of database interface (impl) and wrap the rest of the logic in this class. So, this would leave just the data processing in my Data class and the rest of the logic in a higher level.

Does this make sense?

One more thing. The assignment says nothing about deleting rooms at all. Certainly not in the must section. But I would think that the test would fail a few automatic test if the deleterecord method is not implemented, or?

//Bj�rn
[ June 10, 2007: Message edited by: Bj�rn Tikkanen ]

[Herman Schelti]

hi Bj�rn,

I'm on UrlyBird as well.

My assignment says: "and must implement the following interface", so I'm following the textual description as close as I can.

Since the deleted-flag is not one of the database-fields, I'm not going to make "deleted-flag" a search-criterium. And I will put that in my choices.txt.
But I agree with you that it's not 100% clear from the instructions.

You don't have to do all database-stuff in your Data-class, you could place some of it in other classes and call them from your Data class.

About deleting: it's in the interface of my assignment, but it's not required in the GUI. I will implement it in my Data-class, but the GUI won't be able to use it.
If it's really not in your interface, I would not program it.


Herman

[chris bajada]

When reading deleted records, RecordNotFoundExceptions should be thrown.

Thus when your search mechanism is looping through the dbfile, it will check out only those records which do not throw that exception.

I have the B&S assignment, same here - it did not say anything about deleting records, but my Data.java has to provide the mechanism to delete these records. What I did is I implemented it in my UI and client/server communication for testing, and then deleted it before submitting; leaving it only in the Data.java class.

Rest assured that all the methods in the interface have to be implemented.

I'm currently awaiting response from a local prometric centre... hope to get done soon,

good luck mate

chris

[Jason Moors]

Hi Bj�rn,

To answer your question you need to consider the purpose of the deleted flag. The aim of the deleted flag is to simplify/optimise the deletion of records, by marking the associated bytes for the record as deleted and available to be reused, rather than physically removing from the file.

Following this assumption, it would not make sense to return records that are marked as deleted, as these records do not exist. With this in mind I would suggest that you could easily justify in your design decisions not returning records that are marked as deleted.


An interface is a kind of contract, therefore any class which implements the interface should implement the logic defined by the interface. Have a look at the Facade design pattern for separating logic in the Data class.

Regards
Jason

[Bj�rn Tikkanen]

Good input guys!

I was planning to use Facace pattern for database but there is still a choice where to put some of the logic (if to say it is low level or higher level, but I guess all this can be put in choices.txt hence justified).

I do have the deleteRecord in my interface so it of course has to be implemented (by java terms) to compile, but for my programs sake there is no need to have the implementation do something of value. But, for fun, training and to avoid a stupid failure I will go through with the full implementation (and it sure will be handy in the test phase).