• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Bodgitt & Scarper - Database Record Numbering

 
Ranch Hand
Posts: 206
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I passed the SCJP on November 13th, and this is my first post to the SCJD forum. I've downloaded the Bodgitt & Scarper assignment from SUN. I have a good bit of the Data class written, but I have a simple sounding question for my fellow bloggers.

The records in my flatfile database don't have record numbers. The DBAccess interface (in the project specification) specifies that "long" recNo's should be used to reference database records. There doesn't seems to be any advantage in using the "long" precision of the record number variable by generating random numbers as the records are read. Rather, I just read the records sequentially starting with record number 1 through record number 30 (let's say), and read all the records until I encounter end-of-file. I will never need all the available bits in "long recNo" to encode all of the record numbers in my flatfile database. This makes sense, right? There isn't any reason to generate 64-bit numbers for database record numbers?

I know this question is pretty simple, but my questions are sure to get more difficult.

Thanks,
Harry
 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Howdy, Harry!


There doesn't seems to be any advantage in using the "long" precision of the record number variable by generating random numbers as the records are read.



Generating random numbers? Champion, the thing is simpler: the records don't have a "record number" field, so the record number is the position that each record appears in the .db file.
 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Roberto,
I have the same issue with my B&S assignment about record numbering strategy.


so the record number is the position that each record appears in the .db file.



What the position means?
a) the real byte position of the data block in the db file that used as argument in RAF.seek() method
b) simply ordinal position of the record in file (i.e. 1, 2, 3... etc)

In case of b) how should I treat deleted records? Simply skip them and don't include in numeration order or keep their numbers and throw RNFE when the number of deleted record is requested?
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Andriy,

I would opt for b. But you can't skip them in numeration, because that will lead to big problems. Because you'll use a formula to calculate the starting position of a certain record. something like:
If you have 3 records and the 2nd one is deleted, then the recNo will be:
  • record1 has recNo 1 (or 0)
  • record2 has no recNo (deleted)
  • record3 has recNo 2 (or 1)

  • So instead of reading record3, you will read the deleted record2. And record3 will be read instead of record4,...

    Kind regards,
    Roel


     
    Greenhorn
    Posts: 15
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi,

    I would have to agree with Roel,

    But you can't skip them in numeration



    A deleted record in the database file provide by Sun is not the same as a deleted
    record in an actual RDBMS.

    What this means is, if you were to execute the delete method on your database file,
    you shouldn't completely remove the record information and the record number. Either
    the space which the previous record used to occupy will be available for reuse and will
    be reused when creating a new record, or you can opt out not to reuse the record space.

    Either way, you have to write that deleted (or possibly a new record in its place) record
    back to the file.

    Vlad
     
    Harry Henriques
    Ranch Hand
    Posts: 206
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Vlad Djordan wrote:
    Either way, you have to write that deleted (or possibly a new record in its place) record
    back to the file.



    Hi Vlad,

    I'm somewhere in the middle of designing and implementing a Bodgitt & Scarper SCJD assignment. The first part I worked on was implementing the Interface provided by Sun with methods that are used to modify the flat-file database. The second part I worked on was implementing the GUI. I now have the GUI talking to the database through the business layer. Since my assignment only says that I must be able to search records, update records and book contractors, I'm not concerned with deleting records, or creating records.

    There aren't any record numbers in my flat-file database. Record numbering relies totally on the serial position of a record within the flat-file database. Therefore, you can't physically "delete" a record from the flat-file database, because you would change the record number of every record after the deleted record.

    Regardless, I mark deleted records by writing a byte to the initial field in the records, invalidating them. It is not possible for me to read a record that has been deleted in this manner (by design). I don't have to deal with deleted records in my presentation layer. Reading a deleted record throws a RecordNotFoundException.

    Best regards,
    Harry
     
    Roel De Nijs
    Sheriff
    Posts: 11604
    178
    Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Harry,

    I'm not concerned with deleting records, or creating records.

    I guess you implemented the delete and create methods from the given interface? These methods aren't referenced from the assignment, that is correct. But you have tested your delete/create methods in some way to see if you have implemented it correctly.

    And I guess you have misunderstood Vlad a bit, because he is saying exactly the same thing as you You can't simply physically delete a record from file (because it will mess up the record numbers of the other records), you just set a flag to "deleted" or "valid".

    Kind regards,
    Roel
     
    Harry Henriques
    Ranch Hand
    Posts: 206
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Yes Roel and Vlad,

    I have implemented and tested the createRecord() and deleteRecord() methods in my SCJD assignment, because I was required to implement them. They are unused and inaccessible from the presentation layer because their use isn't required by the specification.

    Best regards,
    Harry
     
    Vlad Djordan
    Greenhorn
    Posts: 15
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi,

    And I guess you have misunderstood Vlad a bit, because he is saying exactly the same thing as you



    I certainly am. Harry I believe your approach is correct. My response was originally just an addendum to the
    answer provided to Andriy, that you can't ignore records marked with the deleted flag and why you can't ignore them,
    and that every record marked as deleted has to find its way back to the file one way or the other.

    Vlad
     
    Greenhorn
    Posts: 3
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator


    Sorry, I think my question's been answered above... Deleted!
     
    Roberto Perillo
    Bartender
    Posts: 2292
    3
    Eclipse IDE Spring Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Mark Blackwood wrote:

    Sorry, I think my question's been answered above... Deleted!



    Ok... so welcome to JavaRanch, anyway!
    reply
      Bookmark Topic Watch Topic
    • New Topic