Just wondering as regarding the create method in the data layer, I know its not used in project but it still needs to be tested. I currently am throwing a nullPointerException if 1 is trying to create a new record based upon nulls. For example . Is this wrong, or would I have to change the way my assignment works? The reason I'm asking is that I have based the assignment about reading in bytes, converting to strings and placing string back to bytes when writing. Therefore all my criteria is based around Strings, is this incorrect, for example, my search method is based upon strings? Would this be incorrect? Should I allow the nulls to be written to file? Also is there a minimum criteria for the create method or could someone potentially just keep entering all nulls for the create method and this seen as valid record.
Champion, I'd say this is an interesting question. We don't really have much information about which fields can't be null when creating a new record. But, looking at the current state of the database, we can conclude that the only field that allows null values is the customer ID. In my case, what I did is verify if the String array that the create() method expects isn't null, and if the Strings in the String array aren't null, except for the customer ID field. If the verification fails, then I throw an IllegalArgumentException.
Other than that:
Is this the signature of the interface that was provided to you? Or it is in the business layer? If it is in the business layer, you don't really have to have it there, as we are not required to provide such functionality.
Sorry Roberto, I'm kind of new to all this. "But, looking at the current state of the database, we can conclude that the only field that allows null values is the customer ID" Is this to do with the "ISO-8859-1" specification and that it permits nulls? Otherwise how do we know? Ya, its the interface to the database, damn that parts right anyway
Is this to do with the "ISO-8859-1" specification and that it permits nulls?
Hum... no. If you look at your database, you'll see that it is filled with blank spaces.
Ya, its the interface to the database...
You mean, the interface that was provided to you, or that you built yourself? If it is the interface that was provided to you, that's weird... I don't have my instructions here right now, but I'm pretty sure it expects a String array. If it is an interface that was built by you, you could make it look more like an OO method... instead of expecting all these parameters, you could expect an Entity (or a Value Object, if we think that the object that represents a Room doesn't even have an identity), or a DTO (if we think in a more procedural way).
Mark O' Sullivan
Joined: Aug 17, 2009
Thanks for your reply Roberto. Apologises of course the create method uses a String array, but excited yesterday. (covered). 2 quick points, the fact the find method can search on all nulls, is it an invalid assumption that a record field itself could contain all nulls? Secondly and this is a ridiculous question, if one sees all all blanks for the CSR field, how does 1 know this is not all blanks and is a null field? Are they encoded differently using getBytes()?
Further to my good friend Roberto and answering your 2 points, yes it is possible to have records that are all nulls.
I recall the instructions schema section saying something on the line of the customer ID field is "null-terminated" having length of 8 character/digits long. Taking this separately makes sense, together not make sense. So is it null terminated? Or all blanks with 8 characters long?
Personally when I did my create method, I use the blanks approach.
Now for the search. I interpreted searching for null returns "all data". And for the customer field, null or blanks means that record is ready for sale (bookable).