• 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

RandomAccessFile & ObjectInputStream

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Everybody !

Is there any way I can read/write Objects in the db file at random locations. ObjectInputStream has no seek() method. RandomAccessFile has no readObject() method. Can anybody help me out with problem?

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

Originally posted by Udham Singh:
Hello Everybody !

Is there any way I can read/write Objects in the db file at random locations. ObjectInputStream has no seek() method. RandomAccessFile has no readObject() method. Can anybody help me out with problem?

Thanks



Unless your project is drastically different than mine, you don't need a readObject method. The file can be read a a RandomAccessFile, the data is encoded as bytes. You will need to convert those bytes to Strings.
 
Udham Singh
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey Peter !

I am sure there is nothing drastically different in my spec. I just thought it would be more OO to have a class called Record. And then have instances of that class read/written to the file. It keeps the code neat and clean.

Here is what I am trying.

class Record implements Serializable {
byte[] name;
byte[] specialties;
// yada yada

}

And then just so simple stuff like,

ObjectInputStream ois = new ObjectInputStream(
new FileInputStream("dbFile"));

Record record = (Record) ois.readObject();


I am sure somebody before me must have wanted to be just as lazy so I was wondering where to start looking in the API to do what I am trying to do.

Also I am aware that I can do this,

Record[] records = (Record[]) ois.readObject();

And then access whatever I want. But ofcourse there is Info section at the start of our DB which is not a mulitple of the record length.

For all that got to the end of this post. Thanks for the patience. Please ignore any silly mistakes in my code. I just wanted to explain what I have in mind.
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Udham Singh:
Hey Peter !

I am sure there is nothing drastically different in my spec. I just thought it would be more OO to have a class called Record. And then have instances of that class read/written to the file. It keeps the code neat and clean.



The project provides an interface that you MUST implement, there is no choice on this. It specifies some very non-OOP functions passing String arrays and longs. If you wish to be more OO about it you could use the Data Access Object pattern and build a DAO that uses the provided interface and provides Transfer Objects to its user. See Core J2EE Patterns for more details on the DAO Pattern.
 
Udham Singh
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Peter !

I'll check it out. I've started implementing Data in the non-OO way so I dont know how much I would change it.
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Udham Singh:
Thanks Peter !

I'll check it out. I've started implementing Data in the non-OO way so I dont know how much I would change it.



Your welcome, I'm going the rich client route and have designed my server to provide exactly the interface described in the project specification. The first thing my client code does is to wrap this in a DAO so that all it deals with are Transfer Objects containing fields defined in their natural types, eg. size is an int, smoking is a boolean and date is a Date. Note that DAO is stateless, this means that questions relating to making network connections, sessions, threads etc, are outside its domain. The DAO is lightweight and is just an adapter between your business logic and a data source.

Various authors have differing terminology for the data objects that are returned by DAOs. The current official J2EE term is "Transfer Object", it used to be "Value Object", and its often called a "Data Transfer Object". The term "Value Object" was abandoned because others, especially Martin Fowler, use that term for things like the String class.
 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm doing exactly what Peter is talking about... probably because that's what I've done quite a few times at work

It's not important for the project so much, but in real life DAOs are quite versatile. If you add a DAO Factory pattern on top of several DAOs, you can switch entire physical data sources out from under a client and they'll never know. This is great for clients that are fickle (ex: "put that stuff in the database, wait, no put it in that flatfile, wait, I want it as a Web Service, er, did I say Web Service? I meant an XML file").

It's also good for using in fail-over mechanisms under certain circumstances. For example if you have pretty static look-up tables used by your app, you can dump them to a non RDBMS source and switch your DAO if the database goes down.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic