This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Reading in the FIle

 
Rahim Nathwani
Greenhorn
Posts: 19
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 961
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 125
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 53
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 19
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 53
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Ranch Hand
    Posts: 232
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Greenhorn
    Posts: 2
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 52
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    I agree. Here's the link: http://aspose.com/file-tools
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic