Hi, First off a thankyou to Thomas and eveyone else who through responding so quickly and thoroughly to *every* post on this list have made the list a real "selling-point" for pushing OJB as the O-R solution for Java in my company.
But now the question... I have a working nested attribute solution thanks to responses to previous posts, but I'm still not 100% happy with it, and I'm wondering if anyone can think of a better way. My problem stems from the way we represent quantities. We represent them as per Martin Fowler's analysis pattern by giving a Quanity object two attributes: amount and unit. Initially we thought we would just store the amount in the back-end according to a standard well-defined "grain" unit for each Quantity sub-class and make conversions from there. However, it is much more flexible if we store the unit alongside each amount, this means that if the grain unit needs to be changed at any stage, it can be, without requiring conversion of existing data and quantities can all co-exist stored in any unit for the same attribute. The Quantity object handles the conversion between units. Currently my OJB solution is to use a type-conversion to handle the storage - one conversion to extract the amount, one for the unit. Both are stored as long integers (a code for the unit) via the javaToSql() method. To rebuild an object though, I have to create a new RowReader for any class that contains a Quantity. The row reader calls the super reflection method, then instantiates new Quantities based on the amount and unit integers stored previously. What would be superb is if the type conversion could cope with pulling out 2 database fields from a row, rather than just 1 - i.e. the row Map came in as a method parameter rather than just the single Object. Then I could use the sqlToJava() to rebuild the Quantity and thus only require a single Quantity type-conversion object. Oh... and why don't we use a 1:1 reference to a separate Quantity table? Because no matter how hard I try, I can't convince people that we shouldn't let customers use Crystal Reports to report directly from the back-end. So in the interest of not confusing customers too much, the denormalisation is necessary. Thanks and sorry for the lengthy post, Gareth. --------------------------------------------- Gareth Cronin Analyst/Programmer Kiwiplan NZ Ltd: http://www.kiwiplan.com Ph (64 9) 2727622 x854 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
