Provided data file and 48-hour rule!

Hi, guys! I was wondering what your opinion was about the dates in the provided data file, and how will Sun ever be able to check if I did my job right if they will look at those outdated dates? My program will not show those records not 48 hours into the future.

Basically I suggest you write a program that creates a new datafile containing random data, with dates randomly spread around the current date. This random data generator is also good for creating other data that you should be able to handle (null terminated strings), currencies with � etc. (I built this in my extended command line client (DOS client) to the Data class)

Can your app handle 10,000 records , 1,000,000 ? (Currently my program chokes at > 10000 records due to memory consumption so I have some work to do to make it scale, or alternativly just write it down in my design doc as limitations of my design).

What happens if two remote clients hits find button searching for all data and you have 1,000,000 records in your dataset? Do they spend an hour waiting without any response from the GUI trying to push all records over the wire? Does the program crash? (np for me using remote iterators - but limit is memory see above)

If you are handling more than say 40 records you could surly have use of sorting too. Random data is good for testing out sorting routines.How about sorting using Collators?

Also this program will allow you to test your Data class using a completly different database for example having 10 columns with 30 character each, a totally different schema but still readable according to Data class specs. AFAIK the GUI does not neccesarily have to handle another database format, just the Data class. (yup! - This means you have to write test functions that are later not included in the app, say in a parallel source tree with coinciding package names)

Originally posted by Anton Golovin: Hi, guys! I was wondering what your opinion was about the dates in the provided data file, and how will Sun ever be able to check if I did my job right if they will look at those outdated dates? My program will not show those records not 48 hours into the future.

Or will they write some?

I suspect they will use a different test file, one that contains up do date data. I've provided a maintenance dialog in my application that allows the user to create, delete, and update records. It lets me build fresh data. You either need to do that or relax the 48hr rule to test your code.

I display records outside the 48 hours, and allow maintenance on them, but don't allow booking.

peter wooster

Ranch Hand

Posts: 1033

posted 13 years ago

Originally posted by Joakim Eriksson:

Can your app handle 10,000 records , 1,000,000 ? (Currently my program chokes at > 10000 records due to memory consumption so I have some work to do to make it scale, or alternativly just write it down in my design doc as limitations of my design).

The assignment doesn't require huge numbers of records. I've used the DAO pattern to provide a means to use an relational database (in my case Oracle) as a substitute for the data server. That's the way to go for large numbers of sorted records.

Joakim Eriksson

Greenhorn

Posts: 25

posted 13 years ago

I agree with you Peter.

I also use a DAO (Data Access Object), TOs (Transfer Objects) for query and results respectivly, and a Value List Handler (or remote iterator as I like to call it). However my DAO goes against the rules of "Core J2EE patterns" as it has state (ie the read cache in form of Collections of all records) so maybe it is really just an adapter after all.

Going for 100,000 records you should probably start thinking about a real RDBMS (like Oracle) instead of handling it yourself. But seriously, considering the effort that is plunged into this app, isn't it reasonable to think it should acctually be usable for a small company? (Guessing 1000+ records, 3+ CSRs) I certainly think so. It doesn't have to be a great app, but it should provide some added value, otherwise it won't be used.

Maybe I got it all wrong, and are overdoing things, but then at least I feel more satisfied with the result, and it will be easier for me to explain and motivate the choices I made if I agree with them myself.

My largest gripe right now is that storing everything in memory does not scale very well at all.

My app is up and running, I'm just considering alternatives (and sometimes even implement them just to see what the consequences are), rethinking and trying to motivate all the choices I've made.

I still think it is a good idea to stress your app with a randomly made up database.

There is no MUST requirement that states that it is only bookings within 48 hours that should be shown in GUI.

They take bookings only within 48 hours of the start of room occupancy.

This only tells us information that the company only take bookings within 48 hours of the start of room occupancy. Nothing about what to show or not in the application. I think it is up to the operator using the app that he not books up rooms in the future. [ September 15, 2004: Message edited by: Mike Vess ]

What you thought was right today may need a refactoring tomorrow...

Joakim Eriksson

Greenhorn

Posts: 25

posted 13 years ago

Originally posted by peter wooster:

The assignment doesn't require huge numbers of records. I've used the DAO pattern to provide a means to use an relational database (in my case Oracle) as a substitute for the data server. That's the way to go for large numbers of sorted records.

I agree. I Skipped the whole idea of indexes, caching and stateful adapter (I did implement it, but was not satisfied with the results ). DAO is the way to go. The DBMS should handle such details if speed is required.

I think you will find that implementing this pattern whilst an excellent exercise is totally OTT for SCJD.

DAO is an Enterprise pattern and no doubt will be required for SCEA. It is stressed in something Sun has written regarding the various certifications that SCJD examines a small sub set of java useage and that other certifications examine other areas. I think this very much falls in to that. Of course if you implement DAO properly I don't see that you would be penalised but you are making life over complex.