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:
PDF to/from standard Java objects (POJOs).
andJava objects to/from Database.
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.
Winston