SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
SCJP 5, SCWCD 5, SCBCD 5
OCPJP 6, OCMJD 6
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:I don't understand the reason behind this approach - what is the benefit? Why did you go with this approach?
Roel De Nijs wrote:
Sean Keane wrote:I don't understand the reason behind this approach - what is the benefit? Why did you go with this approach?
I think I clearly explained in my previous post, so I just repeat myself. Option 1 will cause problems if you want to use that method (or its logic) in a new release when automatic updates of the database file (e.g. each 10 minutes) are added. The record numbers will change, which is not a good thing. And that's why I opted for the 2nd option. Otherwise you need to redevelop and retest your writing logic again when you are adding automatic updates to the application as a possible solution to prevent data losses when you have a server failure.
Roel De Nijs wrote:
When a record was deleted, I just wrote an empty record (together with the deleted flag of course)
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
SCJP 5, SCWCD 5, SCBCD 5
Sorry, my mistakeSean Keane wrote:I think you may have misunderstood me Roel.
Your understanding is spot-on. The reason why I followed that approach is to keep my logic as simple as possible. I don't have to move the file pointer explicitly, it just moves through the file with writing the file. And I always start with an empty record (which is updated with the actual contents of a non-deleted record).Sean Keane wrote:Is my understanding of how you update deleted records in the file correct? If so, what is the idea behind setting all the fields (bar the deleted flag) to be empty?
Jonathan Elkharrat wrote:there's no real difference. it may be easier to just set the flag, indeed, but
this is not a crucial point...
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Roel De Nijs wrote:The reason why I followed that approach is to keep my logic as simple as possible. I don't have to move the file pointer explicitly, it just moves through the file with writing the file. And I always start with an empty record (which is updated with the actual contents of a non-deleted record).
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:Of course this solution assumes you don't want to save the information in the fields of deleted records - I guess this is something to document in your choices.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:This however doesn't make sense with how you describe your approach of dealing with deleted records. You write back an empty record when a record was deleted .-But how do you know it was deleted when you overwrite deleted records in the cache when creating new records?
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
..if you want to use that method (or its logic) in a new release when automatic updates of the database file (e.g. each 10 minutes) are added. The record numbers will change, which is not a good thing
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:What I don't understand now is, why you selectively write deleted records back to the file. What is the reason for this?
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
Roberto Perillo wrote:
Sean Keane wrote:What I don't understand now is, why you selectively write deleted records back to the file. What is the reason for this?
Did you read with attention what Roel and I wrote?
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
Sean Keane wrote:So a deleted record will only get written back from the cache to the file (as an empty record) if it has not been overwritten by a newly created record.
I don't know why you keep talking about selectively writing back deleted records. That's not true. If it's time to write records back to the file, all deleted records (that is all entries with a null-value in my record cache) are written back to file (= deleted flag is set to true and an empty record is written).Sean Keane wrote:What I don't understand now is, why you selectively write deleted records back to the file. What is the reason for this?
Sean Keane wrote:Roel, if I am understanding your approach, then it is doing neither of these.
Using a record cache one of the drawbacks is the possible data loss when server crashes. To prevent this you could use some periodically writing of the cache to the file. With the approach I follow (and not opting for approach B) I can implement this request with my current code. In my case the writeRecordsBackToFile-method is part of the public API of the application (because it's defined in the interface), so this method could be called any time and if you then change the record numbers of the records, you'll introduce big problems. That's why I didn't opt for B.Sean Keane wrote:What I don't understand from this is what are automatic updates and how do they relate to this project?
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:What I am having difficulty understanding is why bother writing deleted records back to the database at all?
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
Sean Keane wrote:If you periodically write the cache back to the file and only ever write back records that aren't deleted, then how can this cause you problems? You haven't lost any data and you haven't modified the record numbers in the cache.
Sean Keane wrote:When using a thin client, the record number is never exposed outside the server.
Sean Keane wrote:When a user deletes a record, one of two scenarios could happen in terms of your file, and in a non-deterministic fashion. The record could be set to an empty record with the deleted flag set to true OR the record could be updated with the information from a newly created record (that was created after the previous record was deleted).
Roel De Nijs wrote:It will cause problems if you have in mind (like I had a few years ago) that you write records back to file and then build the record cache again. And then it's really important that record numbers do not change
This last step is of course not needed, so writing deleted records to the file is not really needed
. But if you always skip them it will be hard to verify if your deleted records are handled correctly when building the record cache
![]()
Roel De Nijs wrote:Now it gets interesting. I have a thin client and the record number is available at the client. I would otherwise not know how a selected record I have booked can be identified (so I update the correct record in the record cache)? The only unique identifier I have is this record number, so it's needed client-side to identify my records (it's not visible to the user).
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:Then my second thought...When designing a solution for this assignment I think a lot of people, you guys included, would have advocated a KISS approach. So why deviate from this approach when it comes to writing the cache back to the file.
Sean Keane wrote:I appreciate your thoughts guys - so what do you think of my reasoning? I could have just followed your approach blindly, but prefer to reason these things out. Also it maybe be useful to others to understand the reasoning behind the approach.
Roel De Nijs wrote:
Sean Keane wrote:Then my second thought...When designing a solution for this assignment I think a lot of people, you guys included, would have advocated a KISS approach. So why deviate from this approach when it comes to writing the cache back to the file.
That's indeed the principle I followed. But what makes you think that it's a deviation from this principle? My code would not be any simpler when not writing deleted records to the file.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:Would you not agree?
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Sean Keane wrote:Yep, I agree, your actual code could not have been any simpler (apart from maybe not overwriting deleted records in the cache - which would use more memory, but would be easier for a junior programmer to understand).
Sean Keane wrote:It's just really how you describe your justification for writing back deleted records. Your reasoning was to allow for future functionality.
SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Won't you be my neighbor? - Fred Rogers. tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|