Reading in the FIle

[Rahim Nathwani]

Hello All

The assignment desciption tells us the format of the file and the database schema.

So it is fair to hard code these values into my assignment.

For example:

Hotel Name is 8 bytes
City is 8 bytes

I have a class HotelRoom with varables

static final int HotelNameSize = 8;
static final int CityNameSize = 8;

Thanks

[Edwin Dalorzo]

Well, actually I load the metedata from the file and store it in a HashMap containing the field names and their size. Then I use those values to decide how to manage the file records.

So basically if the metadata defined in the file header changes the database server should still work correctly. For instance, if somebody adds a new field to the definition or if the size of field changes, the application will still continue to work.

If you hard code those value you will make you application inflexible.

However, since I have not yet presented my assignment I cannot tell that your approach is incorrect. I find it questionable, though.

[Jeremy Botha]

I went one step further and created a Schema object which is populated with the various field values. This object is published to any class in the application that requires the Schema, and it also means that should the underlying database change the rest of the application is insulated.

Hard coding values is almost always a bad idea.

J

[Roy Mallard]

Rahim - not sure which assignment you are doing but in Urlybird 1.3.2 there is a "header" section of the data file that contains the name and length of each field. So if your assignment is similar you should definitely not hard code the field names/lengths.
The field types are not given in the file header, so I also needed to have some sort of seperate schema which matches the data file.

[Rahim Nathwani]

Thanks everyone,

I will not hardcode it!

Roy - Can you explain the following further:

"so I also needed to have some sort of seperate schema which matches the data file"

Thanks

[Roy Mallard]

I mean the field types (string, date, number etc.) are not given in the data file, so you need to get the type information from somewhere.
I currently hard-code the field types in a class, although I might change this to read the field types from a .properties file.

[Stuart Craig]

Originally posted by Roy Mallard:
I mean the field types (string, date, number etc.) are not given in the data file, so you need to get the type information from somewhere.
I currently hard-code the field types in a class, although I might change this to read the field types from a .properties file.

I believe the assignment specifically states what information is allowed in properties files and that doesn't include schema details. I'd suggest that by adopting such a strategy you run the risk of being marked down or failing.

I understand the purpose of what you are suggesting. The requirements state that we should strive for a flexible implementation and that, in turn, implies that the code which does the physical reading from the file should be generic i.e. independent of type and format.

I'm currently trying to introduce this concept into my implementation by injecting into the "file reader" a strategy or strategies which encapsulate the following information:

The relationship between record index and the offset from the start of the file of the specified record;

The relationship between the record as a whole and it's individual fields, and the attributes of those fields (e.g. name, size, type).

This approach gives me the flexibility to vary the behaviour of my file reader by injecting a strategy which contains hardcoded rules and values (possibly of use in early prototyping), or one which expects and reads the UrlyBird schema metadata (the final submission to the examinar), or one which reads a different schema format altogether (for use in some hypothetical future datafile format).

Unfortunately I've hit a mental brick wall whilst trying to iron out the aesthetics of my full implementation. I suspect that I'm too hung up on the style of my solution, but I can't help shaking the feeling that the examiners will mark on style (or design as they might call it).

[Lucy Hummel]

Hi Stuart,

May I ask you where you get the information of the field type you mentioned:

Originally posted by Stuart Craig:

The relationship between record index and the offset from the start of the file of the specified record;

The relationship between the record as a whole and it's individual fields, and the attributes of those fields (e.g. name, size, type).

In my case I only know the type for schema fields. The records/data itself are just maintened as data type: String. To be precise the first record entry is not a String. But it can only have two values:

delted

not deleted

But even theses values can I read as String and compare to final static String attributes to check wheter the record is deleted or not deleted.

Looking forward to your answer.

Br,
Lucy

[Leo Himpth]

Hi

I think creating a schema description class might be overkill. Also, it would be quite difficult to design, because we only know about one schema, and don't have an idea how the schema might change in the future.

Instead, I am thinking about assuming that the Magic Cookie value is tied to the current database's schema.

A supporting argument is that the Magic Cookie value is not given in the format description section of my assignment - if it was bound to the format, then I would expect its concrete value to be explicitly mentioned there. (However, a concrete value is also not given in the data section of the assignment...)

So, basically I am using the Magic Cookie value to determine if the schema of the actual file matches the expectations.

[David Nemeskey]

Hi

I have also created a schema object. The problem I found is, the deletion byte is not described in the header. So even with this object, I had to hard-code it (length of the "record header" = 1, for example).

I have placed a TODO in the db code to refactor it, as because of this, as the schema information is scattered in the file accessor class and the schema class.

Also, you always have to hard-code something, if not else, on the client side (internationalization, or at least sensible error texts).

This seems to be more like a design decision. And a very difficult one indeed.