Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Record number, primary key and FieldInfo[] array considerations

 
Daniel Mazzuca
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are some things in the classes provided (Data, DataInfo, FieldInfo) that I think are not well implemented, for example, there is not need to duplicate the FieldInfo [] array in each record (DataInfo). It is enough to have it once in the Data class. Also there is confusion because of the int ID record number and the primary key (the add() method imposes the first field of the database to be unique). We are tempted to define the first field as the flight number, but I think it is wrong, because we are not going to be able to schedule the same flight for another day. So I concluded we should use the same record number as the first field, in this case translated to string, but we are duplicating the information again (we have the same record number as an int and as string in the first field). This int record number would be useful to identify records in tables that don�t define a primary key. But this is not the case. The database provided imposes a primary key as first field of the database. I am again tempted to erase the int record number from the DataInfo class, but in this case, I should change the signatures and code of some methods provided in the Data class, that implies in a considerable change. The question is, are we able to change the classes provided or we must use them as they are? The instructions don�t say anything about what we can and what we can�t do. Any consideration in this subject would be appreciated.
 
Jerry Pulley
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Daniel,
You raise a number of valid criticisms of the provided classes. I'll try to address some of these, but first I'll make a more general observation.
The Developer assignment presents a very real-world programming assignment. I don't know your background, but in my experience programmers are very rarely privileged to create a new system from scratch - we almost always are tasked to work from some existing base of code. Sometimes the existing code may not be modified at all because other systems depend on it. Even if one makes the assumption (valid in this case) that it may be modified for the new system, such modification produces a bifurcation of the organization's source code, making the task of future maintainence more involved.
I grant that modifications to the provided code could lead to a better system - but at what cost? The existing FBN classes provide a very general, albeit rudimentary, non-relational database - the point is, they work. If you make extensive changes to the existing classes, you'll have gained some (not absolutely necessary) improvements at the cost of significant extra development and testing. Are you (or your organization) willing to bear these costs?
To conclude this preamble, I'll note that the extensions I wrote provide a fairly robust server (strong per-client record locking with a definable lease time, automatic cleanup of stale locks and database connections, etc.) with no changes to the provided classes beyond those necessary to repair the use of deprecated methods. It's perfectly possible to make a great product based on the existing code. Now for specifics.
Agreed that DataInfo doesn't really need to contain the FieldInfo for this assignment; you could just use the result of getFieldInfo() to interpret a DataInfo's contents. You would, of course, sacrifice the generality of the DataInfo class. Currently, client code can be written to use DataInfo without knowledge of Data. If you take the field information out of DataInfo, you're effectively left with a String[] - much less useful.
Regarding the use of the first field as a primary key - this seems a reasonable choice for a simple, single-table database. It could cause future designers to have to modify their logical schemas, but you've got to have some sort of primary key. It doesn't cause a problem for this schema because here airline flights are assigned numbers on a weekly basis (at least, that's my inference from the provided data).
Regarding the use of record number as a primary key - probably not a good idea. The record numbers are mostly used internally by Data, and in the few cases they're externally visible they can be expected not to change during a transaction. In general, a primary key is a feature of a schema, and the record number is largely an implementation detail. Mixing them will lead to trouble.
Conclusion - you'll almost always want to change the code you're given to work with. Even if you have the freedom to do so, think twice about the implications of such changes.
jply
P.S. I haven't submitted my assignment yet, but I've read a lot of discussions from people who have. Some people have modified the existing code and passed; all Sun seems to require is that you have a good justification for all of your design and implementation decisions.
 
Daniel Mazzuca
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jerry,
Probably you are right. My decision will be either to change the minimum possible or change the code provided a lot. I was developing Airline software for a couple of years (flight scheduling, flight controlling, crew scheduling, crew controlling, etc) and I found a lot a trouble in the code and specification provided. Not to mention the point you touched before, that there is nothing in the specification that mention to store who was the client that book the flight, what I assumed is not important for the purpose of the assignment, but critical in a real world software.
In relation to use the record number as the first field, did you notice the comment in the find(String) method that says �For this assignment, the key field is the record number field.� Read all the method comment carefully. This comment and the problem you might have to reuse the flight number, suggested me to use the same record number as the first field (although I will not show it in the UI).
I agree with you that the record number should be internal and transparent to the client part, but for most of all the public methods of Data, you must pass this value, explicitly as a parameter, or as part of a DataInfo parameter. So, the client side must know this number in order to operate the database. You can, of course, wrap the Data class and define new methods that make the record number transparent, but in this case, the client-proxy class we should implement, will not implement the �same� public methods of the Data class, as the requirement says. I confess I have not yet decided what to do with this. I will study the problem carefully before start coding.
Another interesting point you touched is �fairly robust server�. The assignment says we must also implement a local database access (no networking performed), where the database and UI run in the �same� JVM. However, inconsistency problems may occur if, at the same time, one user is using the database locally an others remotely (again, remember that the requirement says the UI and Database must run in the same VM, so you can�t use a local network connection or local RMI lookup to get the same database object). I don�t know if I am going to worry with this problem and I didn�t think too much how to solve it (maybe we should add some lock state in the database file itself). However I am interesting to know if people are taking this subject in consideration. Again, any consideration woul be appreciated, and congratulation, this site is great.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic