Why not use an ArrayList for caching instead of HashMap?

[Bably Das]

Hello all,

Till now after reading the data from the database file I have been storing the data into a
HashMap<Integer, Room>, where the Integer denotes the recordNo. This was solely to deal with null values but later I
realised that I can have a flag to indicate deleted entries.
So instead of a hashMap I can use an ArrayList<Room> where the index is the recordNo -
primary key, and have faster retrieval. But before making the changes I am thinking if I am missing something
if I dont use a hashMap for caching. Any comments in this regard appreciated.

Thanks,
Bably Das

[Roel De Nijs]

Hi Bably,

I don't think there is any problem with your approach. Although I don't know what you mean with "a flag to indicate deleted entries": is it in the Room-object you store in your List? If so, from a design perspective: is it really a part of the Room-object? I think it is not (just like you don't add the deleted flag into the String-array. And what if in a next release a real primary key like the room number is added to the database file?

Just my 2 cents.
Kind regards,
Roel

[Bably Das]

Thanks Roel for your reply. Yeah I get your point about about the next release and have decided to stick to hashMap.
The flag to indicate deleted entries is a boolean variable indicating a valid / invalid record status. I think I need to change the name of the Room class to a more appropriate name of Record class. So the flag forms a part of the Record class but is not used in the String array containing the Record details. Only in the delete method I set the flag corresponding to the recordNo to be false indicating deleted record and it is checked for each record when reading or writing to the database file. Is it the correct approach to deal with delete method? It may be a silly question but I am new to Java and highly appreciate all the help provided.
Thanks a lot,
Bably

[Roel De Nijs]

Hi Bably,

If you rename the object to Record the same question applies: is the flag a part of the record? In my opinion it is not. It is some kind of metadata about the record. Because if the record is deleted, the Record object should not exist anymore (it is deleted). If you use a RDBMS you would use "delete from rooms where id=1" and that particular record is gone. There is a difference with a record that can be active or inactive. Then it would be a part of the record, because the record is not deleted, but just set to active (or inactive).

In my solution I also used a Map as record cache and I simply set the value to the corresponding key (recNo) to null (instead of a String-array). Can't be any simpler: if you have a null-value, the record is deleted. No need to set/check a flag. And don't get me wrong: with your solution is nothing wrong, behavior will be as expected (if implemented correctly of course). But in my opinion it is not the best solution from a higher perspective: the record doesn't exist anymore, but you still have a Record-object (containing all properties from the deleted record, which are also unneeded).

Kind regards,
Roel

[Roberto Perillo]

Howdy, y'all.

Bably Das wrote:I think I need to change the name of the Room class to a more appropriate name of Record class.

Well, I'd say that that isn't very appropriate... we have to think object-oriented, and not in terms of database. The entity in this domain is Room, not Record. We have to be careful, because if we have too many flags or too many "ifs" in the code, then this may be indicating that the code is procedural.

Another thing is, in order to call it Entity, you'll have to include the number of that record in the Room object. In the Domain-Driven Design Quickly book, in the description of Entity it says that:

There are different ways to create a unique identity for each object. The ID could be automatically generated by a module, and used internally in the software without making it visible to the user. It can be a primary key in a database table, which is assured to be unique in the database.

Or, you can control it somehow without having the record number attribute in the object. Then, it would be a Value Object.

What you can do is keep the Room object in a List, and if the record is deleted, then the entry is null (something like, if record 1 is deleted, then yourArrayList.add(0, null)). But you'll have to remember that the entry 0 is record 1, entry 1 is record 2, and so on... and when you delete a record, then you simply set its entry to null.

[Roel De Nijs]

Roberto Perillo wrote:What you can do is keep the Room object in a List, and if the record is deleted, then the entry is null (something like, if record 1 is deleted, then yourArrayList.add(0, null)). But you'll have to remember that the entry 0 is record 1, entry 1 is record 2, and so on... and when you delete a record, then you simply set its entry to null.

I like to add a small remark (just for completeness, because you all know this): a list doesn't behave like a map, so if you use yourArrayList.add(0, null) you have also to call first yourArrayList.remove(0) (or you can afterwards call yourArrayList.remove(1)). Otherwise you are adding an empty record, instead of deleting an existing one. That's why I prefer the Map.

Kind regards,
Roel

[Roberto Perillo]

Roel De Nijs wrote:so if you use yourArrayList.add(0, null) you have also to call first yourArrayList.remove(0)

Right! It is important to call remove() prior to adding the element. If there are no objects in that index, then a IndexOutOfBoundsException is thrown. If you add an element in an index that already has an object, then that element (and all the rest of the list) is shifted one position. I myself used a Map too.

[Bably Das]

Thanks Roel and Roberto for providing such clear explanation to my problem. I will stick to a Hashmap and a Room class and when I delete will make the corresponding value to be null instead of using the record flag. I will come back if I have more doubts and problems.
Cheers,
Bably