DBAccess interface uses long for record number in several methods. Does it mean that I should write application that can work with billions of records? Instructions file does not mention number of records in db file.
I need to know this in order to decide wether I manipulate db via MappedByteBuffer or batch-load entire db into a Map<Long, Room>.
On the other hand, this "findByCriteria" method encourages to use a cache. I am confused now. I wish it would return List<Room>...
You can use a cache without any problem, but of course that could become an issue in the long term. so you can address this issue in your choices.txt and also give some alternatives and/or work-arounds.
You can create an extra interface with another find-method (which extends the given one) and have the Data class implement that one. I did something similar. I don't think it's a good idea to have findByCriteria return a List<Room> object, I would prefer a List<String> instead. Because if you work with Room-objects you make your interface only usable for a database file (or other datasource) containing rooms. You can't reuse the interface for a datasource containing customers, hotels,...
Anton Kuzmin wrote:I'd extend the interface, leave 4 of 7 methods with empty @Deprecated implementations and add new 4 methods in my own interface.
Any specific reason for not using 4 out of 7 methods? If you really think that those methods are useless, then I would suggest that you should consider your design again.
Secondly, it is safe approach to write working code for those methods. e.g. deletion of a record was not must requirement in my case, but I still implemented delete method from interface and wrote working code for that method (which would actually delete a record). Only thing is I didn't invoke that method anywhere (or even expose over RMI)
Anton Kuzmin wrote:I'd extend the interface, leave 4 of 7 methods with empty @Deprecated implementations and add new 4 methods in my own interface. But it's scary. What if I fail because of that
That definitely could happen, because you are violating the must requirement to implement the given interface! So you'll certainly need a good explanation in your choices.txt for doing so and still a bit of luck, so you won't fail.
Anton Kuzmin wrote:This oracle's interface is very general. In the real world people use POJO beans. I don't understand why they put String arrays into exam.
That's an easy one. The company ypu are working for (URLyBird) uses this general interface for the management (crud) of all their datasources (flat files, database),... so that's why it uses String in the method signatures. But no one prevents you from creating an extra business layer with a specific pojo for rooms. So that layer talks to the database layer (using Strings), does the necessary conversions and your client application can work with pojo's, so the only part that's using strings, is the database layer. That's in fact the approach I used and I was able to pass the exam (without having the fear of failing because I broke a must requirement)