Hi, > 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.
Thanks! > But now the question... The OJB team is quite familiar with the "Say thanks first, then ask tricky questions" pattern, thus I assume some very tricky question will follow below... :-) > 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. Nice example for combining RowReader and FieldConversion! > 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. In the early days we had a solution called ConversionStrategy which worked in this way. We dropped it as users found that it would be much easier to reuse Conversion Classes if they were defined on a per attribute basis. The problem you are describing is a special case (your ER model violates normalization). So I don't think that there will be a big lobby supporting your request. > 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. Cool argument! I propose to push this concept one step further: why not have a totally denormalized database with only one table? This will allow Excel users to understand your system :-) cheers, Thomas > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
