The reason why I'm creating this mapping is so that I can have a method that looks into this hash map, find a PDF field name/database column pair, retrieve the value of the database column, and set the field name to the value of the database column.
Why not rather than putting a database column name in the map, put an object which can retrieve what you want from the database in the format that you want.
So a Map<String, DataFetcher> where the DataFetcher interface provides a getData() method.
That way all you have to do is mapper.get("VehicleMake").getData() and you have the value you want.
The standard implementation of this object might just map to a single database column in a resultset.
For VehicleSold you could map to three and format the date appropriately - but your PDF building code doesn't have to know anything about that - all it needs to know is to call 'getData'
In fact, then why not get rid of the map altogether, and just write a data retrieval interface for each of the fields you want?
Is the information being included in the PDF going to change at all? Do you know what data it is you are going to want to retrieve? If so, write an interface for it.
That then lets you test your PDF generation code without actually having to have a database, because you can then just stub that interface.
Alissa Horner wrote:I have a hash map that contains PDF field names and their corresponding database table columns. For example, the PDF field name "VehicleMake" is mapped to the database table column "MakeOfVehicle." I have one PDF field for the date when the vehicle was sold "VehicleSold", but I have three database table columns that are used for the date when the vehicle was sold, "MonthofSale", "DayOfSale", and "YearOfSale." Do you think it is a good idea to combine all three database table column names "MonthofSale", "DayOfSale", and "YearOfSale" and map it with "VehicleSold" in a hash map?'
I hate to say, but I suspect you're much too close to this "problem" at the moment, and consequently you're getting bogged down in implementation details.
Clearly, there ISN'T a 1:1 correspondence between your PDF "fields" and your database columns (why, I have no idea; but that's a different question), so you're going to need some way to do the translation.
The question then is: is this relationship 1:many, or many:many? - ie, can one database column EVER map to more than one PDF field? If the first, you may be able to use some sort of MultiMap (or indeed, a Map<String, List<Something>>); if the latter, then you're likely to need some kind of bi-directional Map.
However, even that may be getting ahead of things, because right now I have no idea what this program is supposed to be doing. Is it simply a database-to-PDF (or vice-versa) converter? Or are you likely to need to DO anything in Java with the interim data?
If it's just a converter, you may be able to get away with a direct conversion from your PDF table to a ResultSet (or vice-versa); but if it isn't - and possibly even if it is - you might be better off treating it as two separate problems:
And both sides have a hidden complication: Java is statically-typed.
While you're just translating names, it's reasonably simple; but as soon as you start having to translate data, you're potentially into a "reflective" situation - ie, something, somewhere has to know that "VehicleSold" is a java.util.Date; not just a String that looks like a date. And if you're not very careful, that could lead to a LOT of brittle "dispatch" logic.
My suggestion would be:
1. Get a handle on the types of conversion you're going to need to do - eg, String to Date, String to Integer, Date to String, etc - for both ends of the translation.
2. Create objects that match each of the fields/columns you're going to need to convert and include the conversion type (and probably the source/target "name") with it. One possible way to do this might be with enums, because you can give those meaningful names; but you could also use config files.
3. Create Java classes that handle "rows" of data; either from the database, or from your PDF tables. I suspect you'll find that's the natural mapping anyway - although it may well be different from the DB side than it is from the PDF one - which is just one more reason to treat the two conversions separately.
HIH. I suspect you have a fair bit of work ahead of you.